Voxel rendering for S/W ports

[andrewj]

I have been working on a voxel renderer written from scratch for source ports like Chocolate-Doom which use software rendering.  It is designed for Cheello's voxel pack, and has reached a usable state.

 

Obligatory gif:

 

Repository here: https://gitlab.com/andwj/voxel-rend

 

I plan to make some Windows binaries soon, though this project is not about creating a new source port, but providing code which existing source ports may incorporate if they want to.

[plums]

Wow, that's pretty cool! Was there anything in particular that inspired this?

 

Will be interesting to see which ports end up using this.

[Dark Pulse]

Andrewj is the dude that takes a lickin' and keeps on tickin'.

 

Thank you for over 20 years of great contributions to the Doom community!

[Individualised]

Do any ports have "real"/Build-style voxel renderers like this one? Pretty sure GZDoom at least just renders voxels as cubes which doesn't look very good at all.

[dasho]

This feels like such a casual post for such a cool announcement.

[Alaux]

So I got a bit too excited...

Spoiler

 

No guarantees that this will make it into the port. It's fairly buggy ATM and I'm surprised that a novice like me managed to get it working at all.

 

Edited November 8, 2023 by Alaux

[No-Man Baugh]

To quote jan Misali:

"i'm a bit excited"

[andrewj]

4 hours ago, plums said:

Wow, that's pretty cool! Was there anything in particular that inspired this?

The existence of @Cheello's voxel pack is what inspired it :)

[Lobo]

5 hours ago, Dark Pulse said:

Andrewj is the dude that takes a lickin' and keeps on tickin'.

 

Thank you for over 20 years of great contributions to the Doom community!

Quoted for truth.

[tomas7777]

When I read the title, I thought it was gonna be someone asking if it was possible or requesting it. Then I opened the post and was like "WAHH IT'S DONE ALREADY?!".

[slowfade]

This looks so good! Such a cool idea. For some reason I never thought that this could be implemented in vanilla ports. But it seems obvious now that of course it could be, why not? I'll definitely try this once it's easier to set up.

 

How demanding is the code of hardware? Could this eventually be seen in a real DOS port? Could it run with the processing power of an old PC?

[esselfortium]

Incredible work!

[DankMetal]

Oh man, i need something like this, gzdoom runs like shit on my old pc, and voxel doom would probably make it implode, so having this for lighter ports like PrBoom or crispy would be neat

[_sink]

SO COOL

[Bank]

Really amazing!

[fabian]

Thank you very much @andrewj for the implementation, @rfomin for adapting it to Woof and everybody else involved for their input!

 

https://github.com/fabiangreffrath/woof/commit/afd707b18105cfe7db2b5e3dc696a2344e3a3c08

[liPillON]

oh sweet, so the zip downloaded from cheello's moddb page works straight out of the box in woof now.. excellent!

[Jakub Majewski]

Interesting. From what I understood, the way GZDoom renders voxels is that every single voxel is rendered as a separate cube, all sides are rendered regardless if they can be seen from the outside or not. That's why mod authors generally recommend to use regular 3d models isntead, as they are better for optimisation.

 

I wonder if this new approach in this thread is better optimised and doesn't render the sides we don't get to see.

[bradharding]

This is some awesome work @andrewj! I am very much considering implementing this in DOOM Retro. (It certainly has been requested before.)

[dasho]

4 hours ago, Jakub Majewski said:

Interesting. From what I understood, the way GZDoom renders voxels is that every single voxel is rendered as a separate cube, all sides are rendered regardless if they can be seen from the outside or not. That's why mod authors generally recommend to use regular 3d models isntead, as they are better for optimisation.

 

I wonder if this new approach in this thread is better optimised and doesn't render the sides we don't get to see.

 

I'm almost certain that GZDoom would "hollow" out voxels and essentially make them models. Even with this hollowing, the nature of voxels will still likely give it a hefty triangle count versus a "normally shaped" 3d model.

[No-Man Baugh]

3 hours ago, dasho said:

 

I'm almost certain that GZDoom would "hollow" out voxels and essentially make them models. Even with this hollowing, the nature of voxels will still likely give it a hefty triangle count versus a "normally shaped" 3d model.

would rendering the voxels as actual individual pixels like how GZDoom's software renderer works help or hinder performance?

[dasho]

52 minutes ago, No-Man Baugh said:

would rendering the voxels as actual individual pixels like how GZDoom's software renderer works help or hinder performance?

 

Hmm, honestly I can't speak to this very well as we are stuck in OpenGL 1.x land, where hollowing out the voxels is the difference between "pretty bad" and "pretty ugly". With modern/instanced rendering and such it may be a wash either way at these counts.

[andrewj]

On 11/12/2023 at 12:21 AM, liPillON said:

oh sweet, so the zip downloaded from cheello's moddb page works straight out of the box in woof

Well my implementation cannot use the PK3 directly, it requires all the voxel (KVX) files placed into a directory first.

 

@fabian and @bradharding (and @Cheello of course) I did want to say that I think it would be best to create a WAD containing all the voxel files, and use that instead of either loading from a directory or requiring ZIP support to use PK3 file as-is.  I think it would need a new namespace, like VX_START and VX_END markers.  Something like this may already exist in the ZDoom ports though, if it does then ideally it should be compatible with that system.

 

Plus using a WAD file means that voxel models can be used on-demand via W_CacheLumpName/Num, which would mean the default zone size could probably be a bit smaller, may even allow running on a DOS machine with 32MB of ram.  Would means some non-trivial changes to the code which I'm willing to do.

 

P.S. I'm not super satisfied with the way items are handled, there is a planned option to either force them to be rotated or leave the as-is, I think it probably should default to off (no rotation), and may need more fine-grain control.  The voxel models for the soul sphere, invis sphere (etc) are rather weird, and I tend to think it is easier to simply not have a model at all (and fallback to the sprite) rather than force them to face the camera.

Edited November 13, 2023 by andrewj

[Alaux]

3 minutes ago, andrewj said:

@fabian and @bradharding (and @Cheello of course) I did want to say that I think it would be best to create a WAD containing all the voxel files, and use that instead of either loading from a directory or requiring ZIP support to use PK3 file as-is.  I think it would need a new namespace, like VX_START and VX_END markers.

I proposed something like this to Fabian et. al when they were working on implementing this voxel-support code into Woof, but the idea was pushed aside due to .kvx's lack of a header, which makes voxels hard to identify. I don't quite get the problem, though; if they're in a namespace specifically for voxels, what needs to be identified? Maybe I misunderstood something.

 

I thought about combining the VX_ namespace concept with prefixing (or maybe suffixing) of the lumps in the namespace to prevent ports that don't expect voxels from trying to load them as sprites. Then again, I'm not sure if said ports even try to load sprites from outside the S_ namespace; if they don't, the prefix might be unnecessary.

[rfomin]

24 minutes ago, andrewj said:

Well my implementation cannot use the PK3 directly, it requires all the voxel (KVX) files placed into a directory first.

  

@fabian and @bradharding (and @Cheello of course) I did want to say that I think it would be best to create a WAD containing all the voxel files, and use that instead of either loading from a directory or requiring ZIP support to use PK3 file as-is.  I think it would need a new namespace, like VX_START and VX_END markers.  Something like this may already exist in the ZDoom ports though, if it does then ideally it should be compatible with that system.

 

The thing is that Woof can load *.zip/*.pk3 files directly, so "voxel_doomII_v2_1.zip" from moddb.com works as is in the dev build. It would be great if there was a cross port standard.

 

3 minutes ago, Alaux said:

I proposed something like this to Fabian et. al when they were working on implementing this voxel-support code into Woof, but the idea was pushed aside due to .kvx's lack of a header, which makes voxels hard to identify. I don't quite get the problem, though; if they're in a namespace specifically for voxels, what needs to be identified? Maybe I misunderstood something.

 

If we add a new namespace, no identification is required. The problem is that other ports must be modified to support or ignore this new namespace, in particular PrBoom+ and others.

[Alaux]

1 hour ago, rfomin said:

If we add a new namespace, no identification is required. The problem is that other ports must be modified to support or ignore this new namespace, in particular PrBoom+ and others.

That's precisely why I proposed combining the namespace with a prefix in lump names: so that other ports don't mistake voxels for sprites. It could still be an issue if a WAD uses graphics or textures which happen to have the same name as voxels, though.

[SilverMiner]

Cool, I didn't expect voxel renderer alone to appear so soon

[viti95]

Really interesting, I really want to see this running natively on a 486/Pentium.

[JadingTsunami]

4 hours ago, Alaux said:

That's precisely why I proposed combining the namespace with a prefix in lump names: so that other ports don't mistake voxels for sprites. It could still be an issue if a WAD uses graphics or textures which happen to have the same name as voxels, though.

 

A lump name prefix seems like it could work to me by combining the 4-letter identifier (which is unique) and the prefix, like "VX_BOSS" for the Baron voxel.

 

At that point I am not sure the separate namespace helps much. Already namespaces are not enforced for sprites, so I'm not sure enforcing it for voxels specifically would provide a benefit.

[Alaux]

1 hour ago, JadingTsunami said:

At that point I am not sure the separate namespace helps much. Already namespaces are not enforced for sprites, so I'm not sure enforcing it for voxels specifically would provide a benefit.

The purpose of the namespace would be to tell the port with voxel support that lumps in it are indeed voxels, in case a WAD just so happens to have other lumps with the same names.

 

As I put it while the Woof devs were implementing this: use a VX_ namespace to tell our voxel-supporting port that the lumps in that namespace are indeed voxels, and also use a prefix or suffix to not confuse non-voxel-supporting ports into trying to load voxels as sprites.