Voxels?

[randi]

R_LoadKVX in ZDoom is also not from Build. All Build does is load the raw data into memory and assumes it's a proper format with all five MIP levels present.

writing up some sort of documentation regarding the MIP stuff

I can tell you right now, the MIP stuff is just sized-down copies of the voxel data stored consecutively in the file, just like MIP levels for textures. The first level is the original image, the next level has all dimensions cut in half, the third level is cut in half again, and so on. So you pick which one to use based on how far the voxel is from you.

The only other specific KVX feature is the back face culling info. It's just a bitfield for each post that describes which faces are visible. It's only needed because KVX discards interior voxels that are never seen anyway and would be a waste of time to render. You can get the same information from VOX by actually looking at the neighboring voxels. (Though KVX is more efficent, since you find out for several voxels all at once instead of having to check each one.)

Rendering the voxel amounts to stepping through the object from back to front in the X/Y plane and drawing each column down in the Z plane, just like sprites. Finding the column data is just like finding the column data for a Doom patch, except it uses a two-stage lookup, as described in the slab6 documentation.

[Xaser]

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

What's the consensus on this? I'd love to be able to use a Voxel decoration or two in HacX if both ports are shooting for support.

[esselfortium]

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

What's the consensus on this? I'd love to be able to use a Voxel decoration or two in HacX if both ports are shooting for support.

Don't quote me on this, as the plans might change again, but I'm pretty sure Quasar's planning on supporting both formats and using an EDF lump that allows users to specify a format on a global (i.e. for all voxels loaded from that wad) basis, as well as making per-lump exceptions. That way it's kept simple and straightforward while still avoiding the need to either muck up the lump names or guess at formats, which Quasar doesn't consider to necessarily be reliable enough to depend on as an end-all be-all solution. Personally, I can see either side of the specification-vs-detection argument, but I don't think this is a bad solution. For probably almost all wads it'll be as simple as defining the format you're using once, in one place, and never having to worry about it again.

[NeuralStunner]

VOXELDEF? Something like this?

Code: Select all

Default KVX;

Format BON2A0 VOX;
Format BON2B0 VOX;
Format BON2C0 VOX;
Format BON2D0 VOX;

[Graf Zahl]

and using an EDF lump that allows users to specify a format on a global (i.e. for all voxels loaded from that wad) basis, as well as making per-lump exceptions.

If he is dead set on doing it the stupid way, fine. In that case I certainly won't try to help create a unified specification. It could be so simple: Use VX_START/VX_END, name the voxel SPRTx with x being the frame character and you're done. Gez's identification code for Slade is good enough. So far I had not a single false identification with it as a proper VOX file can't possibly be identified as KVX and vice versa. There's no need for external definition data and no need for putting the decision which format to use on the modder's side which is just wrong!

If he does it like you describe the end result will be the same as with other features: People won't bother making it compatible with both and Eternity will be left by the side again.

VOXELDEF? Something like this?

Code: Select all

Default KVX;

Format BON2A0 VOX;
Format BON2B0 VOX;
Format BON2C0 VOX;
Format BON2D0 VOX;

no, No, NO!!!
Read my post and all the stuff I said over at Doomworld.

[esselfortium]

If he does it like you describe the end result will be the same as with other features: People won't bother making it compatible with both and Eternity will be left by the side again.

This seems rather backwards. After years of turning down requests to add it, ZDoom implements voxel support within several hours of an early commit being made for voxels in Eternity, then the ZDoom developers make demands about how they think it should be done, refuse to compromise, and make bizarre threats about what will happen if Quasar doesn't fold and do it exactly how they want it. What a load.

[Graf Zahl]

I certainly won't add stupid conventions that makes the modders' lives more complicated just because Quasar is paranoid.

As I said before: I trust a decent format analyzer 100 times more than expecting a modder to always get it right. If he wants to add a needless cause of errors to his engine, fine, but then he'd be alone with the problems.

I want to keep this simple and straightforward, with minimal fuss. Once such idiocies are introduced that's no longer doable. It's comparable to not trusting Doom patch graphics to be reliably identifiable. ZDoom had this once and expected the user to play by certain unintuitive rules or the game would crash. These crashes went away once I added a proper format checker to the texture loader instead of letting it just assume format correctness. Same problem here. We have different formats that should be freely mixable without having the modder to think about the finer details. It can be done so it should be done. Unlike models we have a 1:1 mapping of sprite frames to voxels here so there's absolutely no need for any kind of definition data - unless your paranoid concerns get in the way of doing it right, of course.

[Gez]

I don't know why Randy decided to start a voxel branch; though if I had to guess I'd say it's part of his long-term project to one day create a ZBlood port. Why now? The restart and possible completion of the Doom Voxel Project provides a point.

[esselfortium]

I certainly won't add stupid conventions that makes the modders' lives more complicated just because Quasar is paranoid.

As I said before: I trust a decent format analyzer 100 times more than expecting a modder to always get it right. If he wants to add a needless cause of errors to his engine, fine, but then he'd be alone with the problems.

I want to keep this simple and straightforward, with minimal fuss. Once such idiocies are introduced that's no longer doable. It's comparable to not trusting Doom patch graphics to be reliably identifiable. ZDoom had this once and expected the user to play by certain unintuitive rules or the game would crash. These crashes went away once I added a proper format checker to the texture loader instead of letting it just assume format correctness. Same problem here. We have different formats that should be freely mixable without having the modder to think about the finer details. It can be done so it should be done. Unlike models we have a 1:1 mapping of sprite frames to voxels here so there's absolutely no need for any kind of definition data - unless your paranoid concerns get in the way of doing it right, of course.

This is a comically absurd amount of fuss to be making over a lump that in almost all cases will consist of exactly one simple line. You've made this out as though it'd somehow be a dealbreaker for anyone looking to make cross-port projects; I can't imagine that the cross-port HacX project Xaser is working on would be particularly fazed by the need to write out one extra line specifying a voxel format, considering that they have quite a lot of DECORATE that they are already aware will need to be converted to the equivalent EDF for cross-compatibility.

Anyone doing a project aiming for ZDoom and EE cross-compatibility has bigger and more relevant things to concern themselves with than this molehill you're attempting to make a mountain out of, and it's just making you look like a bully. This slight difference in implementation will have no real effect on modders, but you've used it as an excuse to throw around ZDoom's clout and show everyone yet again that you can forgo even any illusion of compromise or the creation of a standard because, hey, you're ZDoom and whatever you do will automatically be considered the right way, no matter what, and any other developers who either can't or don't want to do it the same way are just screwed. Even if they're actually not in anyone's mind but your own, as in the current discussion.

[Kate]

This is a comically absurd amount of fuss to be making over a lump that in almost all cases will consist of exactly one simple line.

This.

This slight difference in implementation will have no real effect on modders, but you've used it as an excuse to throw around ZDoom's clout and show everyone yet again that you can forgo even any illusion of compromise or the creation of a standard because, hey, you're ZDoomGraf Zahl and whatever you do will automatically be considered the right way, no matter what, and any other developers who either can't or don't want to do it the same way are just screwed.

And this.
(And those who can will probably not care.)

[Graf Zahl]

Anyone doing a project aiming for ZDoom and EE cross-compatibility has bigger and more relevant things to concern themselves with than this molehill you're attempting to make a mountain out of, and it's just making you look like a bully. .

Yes, it's absolutely absurd to tell the program what format a lump is in when it can (and should) determine that itself.

Even if the lump was there I wouldn't trust its contents and analyze the voxel lumps myself (see my remark about crashing on malformed Doom patches) making the whole thing an utterly pointless exercise. So again: Why? I see no other reason than to accomodate Quasar's unfounded paranoia.

[Voxel]

I stopped playing Doom a long time ago because all the objects and characters are flat and 2D. 2D is extremely boring and unimmersive when compared to 3D.

Slab6 is a very simple user-friendly program that everyone can learn how to use (unlike programs like Blender that is cluttered with advanced features n shit)
Slab6's integrated palette editor for example is extremely easy to use: it's so fucking simple it's genius.

[Marisa the Magician]

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[esselfortium]

Anyone doing a project aiming for ZDoom and EE cross-compatibility has bigger and more relevant things to concern themselves with than this molehill you're attempting to make a mountain out of, and it's just making you look like a bully. .

Yes, it's absolutely absurd to tell the program what format a lump is in when it can (and should) determine that itself.

Even if the lump was there I wouldn't trust its contents and analyze the voxel lumps myself (see my remark about crashing on malformed Doom patches) making the whole thing an utterly pointless exercise. So again: Why? I see no other reason than to accomodate Quasar's unfounded paranoia.

FYI I don't know or care enough about the voxel formats to have a position on whether your system is reliable and futureproofed enough to use. I'm not arguing about whether you're right or wrong. You didn't attempt to have a discussion about your difference in opinion and propose your reasons for preferring a different implementation; you instead chose to take this opportunity to behave like a middle-school bully boasting about his ability to steal your lunch money. It's arrogant, self-serving, and childish as hell, and you know it.

[Karl Murks]

Graf is right though.

The formats are identifiable so there is no need for an external identification method.

So what this entire discussion, both here and at Doomworld, boils down to is Graf saying that it's not necessary and you countering him, based apparently solely on the fact that the creator of your pet port voiced concerns which appear to stem from a lack of investigating the specs. And then you act surprised when Graf gets a bit more aggressive when it becomes clear that some people are hell-bent on doing it wrong? You even admit now that your own technical knowledge is not sufficient to have an opinion. So what gives?

What I do not understand though is that so many people are listening to the technically unfounded opinion just because the sound one comes from a person some people apparently have issues with.