Voxels?

[Karl Murks]

I just saw the new Voxels branch in the changelog.

Interesting, very interesting. I guess many people have been asking for that so it's certainly appreciated.

However, this begs the question, what happened to Doomscript? Is this still being worked on. The last change there was many weeks ago. A status update of this feature would be nice.

[Nash]

There's also the scripting branch. Also, Randy can work on whatever he feels like working on, whenever he feels like it.

What would be more interesting though - is GZDoom also going to support this?

(Well I'm guessing once the voxels actually work, it wouldn't be too difficult to port it over to OpenGL)

[Gez]

I guess this thread might have been the catalyst.

[Nash]

Okay so I just read through the thread and apparently the issue of drawing voxels in OpenGL isn't a trivial one.

Regardless, I think this is an interesting development... sadly, there aren't any modern tools available to actually produce any content (slab6 or whatever that was back then was very clunky and uncomfortable to work with last I used it).

I know of that editor that's linked in that DW thread but it costs $189 - too expensive. I might as well model something in Milkshape 3D which only costs about $25 and use a converter to convert the model into a voxel model.

Speaking of which, using a modeller to create voxel models kind of takes away the novelty out of voxel modelling...

[Graf Zahl]

There's also the scripting branch.

I believe the question was not about the presence of that branch but about the lack of recent updates.
Well, about that, progress has been generally slow and 3 week breaks between updates are not uncommon. But for a true status report Randy has to answer, of course.

Concerning the voxels, I see that it only loads KVX format, but looking over the stuff at Doomworld I see lots of VOX objects. Will this be supported, too? Also, I think the data maintenance needs to be a bit less tied to the software renderer. Remapping the colors during the loading of the objects makes the current code rather useless for GZDoom.

In general, since Eternity also just started adding some Voxel support, I think that both data formats and storage methods should be kept identical.

[DooMAD]

Regarding the multiple formats, there's no problem converting VOX to KVX, so whichever format you decide to agree on is fine by me. It's as easy as converting a GIF to a PNG.

Although, as suggested on the Doomworld thread, I've popped over here to find out which "mip" setting I should be using when converting the VOX files to KVX. Is it 1 mip or 5 mips? Apparently the Build Engine needs 5 mips, but obviously I have no idea how ZDoom's implementation is going to differ from that.

[randi]

KVX is the only reasonable format for the software renderer to use. VOX is just a big block of voxels and nothing else. KVX is essentially Doom's patch format extended to 3D, so it also has an origin point, solid voxels are conveniently grouped into runs, and it has backface culling information built in to the voxels.

You can use either 1 or 5 mips, but 5 would be better so the engine doesn't have to do as much work rendering voxels that are further away.

Remapping the colors during the loading of the objects makes the current code rather useless for GZDoom.

So convert to a model before the remap.

[Caligari87]

How will these voxels be rendered, out of curiousity? Voxelstein looks like shite IMO, but Blood has a nice style to the rendering.

[esselfortium]

KVX is the only reasonable format for the software renderer to use. VOX is just a big block of voxels and nothing else. KVX is essentially Doom's patch format extended to 3D, so it also has an origin point, solid voxels are conveniently grouped into runs, and it has backface culling information built in to the voxels.

For ports that can't just use Build code to do the rendering for them, is the KVX format open and documented?

[Snarboo]

I'm glad to see this is finally being considered. It's something I feel would look right at home in the software renderer.

[Graf Zahl]

KVX is the only reasonable format for the software renderer to use. VOX is just a big block of voxels and nothing else. KVX is essentially Doom's patch format extended to 3D, so it also has an origin point, solid voxels are conveniently grouped into runs, and it has backface culling information built in to the voxels.

For ports that can't just use Build code to do the rendering for them, is the KVX format open and documented?

Yes, there's something in the slab6 download.

Concerning VOX, I don't think it's a good idea not to support it. If necessary it should be converted into something usable just like textures - but I somehow see this as the format that''ll be most widely available.

[randi]

For ports that can't just use Build code to do the rendering for them, is the KVX format open and documented?

The procedure for drawing VOX in the Doom engine would be exactly the same as KVX, except KVX is already optimized to make it easier. Where the code comes from is a non-issue. If you're familiar with the format of Doom patches, KVX is exactly the same thing in 3D (with minor differences in the header of each post, since they were made by different people).

but I somehow see [VOX] as the format that''ll be most widely available.

If it does, that would be very sad. It doesn't even let you specify an origin point in the mass of voxels.

[Caligari87]

Well stick with KVX, and once it's implemented I'm sure folks will start using it more; I think most use VOX because it's supported by other software.

[esselfortium]

For ports that can't just use Build code to do the rendering for them, is the KVX format open and documented?

The procedure for drawing VOX in the Doom engine would be exactly the same as KVX, except KVX is already optimized to make it easier. Where the code comes from is a non-issue. If you're familiar with the format of Doom patches, KVX is exactly the same thing in 3D (with minor differences in the header of each post, since they were made by different people).

but I somehow see [VOX] as the format that''ll be most widely available.

If it does, that would be very sad. It doesn't even let you specify an origin point in the mass of voxels.

I see. Since other ports can't use the Build code directly as a base like you've done, and are iffy on the legality/morality of using it as a direct reference, would you be opposed to writing up some sort of documentation regarding the MIP stuff and the other KVX-specific benefits and how they can be handled, other than just ignoring them?

[Gez]

Documentation already exists. Look here for implementations of format detection code. As you can see, it is rather simple. It was written without looking at any line of Build code; just the specs given in slab6's text file.