Voxels?

[Graf Zahl]

I honestly don't care what Eternity finally does, as long as it does not force some stupidity into a potential cross-port standard. And sometimes very clear words are needed to ensure that.

If Quasar absolutely won't trust an analyzer, fine - but then he should do it in a way that does not become an obstacle for others.

[DavidPH]

Am I the only one who thinks that an analyzer makes a good fall-back, but should allow overriding in the (admittedly extremely unlikely*) scenario that it wouldn't work? I understand Quasar's concern that it's possible in the future that extensions could be made to existing formats (or new formats made/employed) that make the format ambiguous to an analyzer. At the same time, I agree with Graf that needing a file just to describe what can already be gleamed by the engine is more hassle than its worth for most use.

So perhaps a good solution would be a VOXDEFS that acts simply as a means of resolving potential ambiguity. Ports that implement a full analyzer could use it as a starting point to increase efficiency or simply ignore it. And ports that don't want to use an analyzer (right or wrong) can take it as The One Truth (presumably with some sanity checking to report errors, but that's purely implementation concerns). Or the intermediate possibility of an analyzer that concludes the format is ambiguous and thus falls back to the VOXDEF.

*Extremely unlikely is not never. Lots of extremely unlikely things have come back to bite people.

[Chris]

I understand Quasar's concern that it's possible in the future that <i>extensions</i> could be made to existing formats (<i>or new formats</i> made/employed) that make the format ambiguous to an analyzer.

I'd certainly hope that if a new format is made, it will be given a proper identifying header. Any new format that can't reliably be detected by looking at the start of the data just needs to die in a fire. And if you're going to make extensions, you're better off making a new format so you don't confuse existing tools.

[Mancubus II]

I don't have much time to make this post so I'll keep it brief.

Despite what I may think about Graf's methods of presenting his point (let's say it leaves much to be desired), in this case he is right. In fact, I'd argue that randy is right. Let's face it, there hasn't been a lot of movement in the world of voxel formats. Do we really expect that some format extension is going to come along that makes it worthy enough to update engines? I suppose crazier things have happened, but no matter how you're detecting formats, I don't see how you can make either method "futureproof". Such a thing doesn't exist absolutely. For that, it makes perfect sense to support the KVX format (and based on what randy has posted, it seems the VOX format doesn't contain as much critical info to make things easy).

The ONLY place where I can see a custom definition being required is http://moreplease.free.fr/HRP/Devan/scr ... reen27.jpg. I think we can all agree being able to do that is pretty cool. Such a thing would be perhaps possible using just the marker/sprite replacement, but it would be difficult. I could see being able to clamp voxel switch replacements done in port specific ways unless THAT can be agreed upon.

So to sum, in this case Quasar is incorrect in having edf do anything for the basic implementation. It's clear that it's not necessary. If quasar wants to be considered "the first" it's important to start out thinking in as vanilla of a way as possible FIRST to allow maximum port compatibility. For the advanced funky stuff, that can be hashed out.

No VOXDEF, no VOXINFO, we don't need another definition lump. The advanced stuff can probably be done within existing frameworks.

[Graf Zahl]

Am I the only one who thinks that an analyzer makes a good fall-back, but should allow overriding in the (admittedly extremely unlikely*) scenario that it wouldn't work?

No. That's like saying 'This is a WAV file even though its header says 'AIFF'. If the analyzer can rule out one of these formats it can't be it. Period. That is, unless someone made a non-standard extension but that'd be a different format.

I understand Quasar's concern that it's possible in the future that extensions could be made to existing formats (or new formats made/employed) that make the format ambiguous to an analyzer. At the same time, I agree with Graf that needing a file just to describe what can already be gleamed by the engine is more hassle than its worth for most use.

Anyone who defines an extension to a format without proper identifiers deserves to be hanged, drawn and quartered. I agree with Chris that such formats should die in a fire - most painfully. Unfortunately 15 years ago when this crap was designed this awareness did not exist. So any future Voxel format extension needs to take this into account and define a proper header. And don't worry about misidentifications. If you define a 4 character identifier only it's enough to discount the new format as both VOX and KVX because the voxel sizes would be clearly out of bounds.

*Extremely unlikely is not never. Lots of extremely unlikely things have come back to bite people.
_

The possibility of VOX and KVX to be cross-misidentified is zero, unless you have some intentional fringe cases that serve no real purpose. If there's a valid KVX structure it really can't be VOX. As soon as other formats come into play that could be misidentified as both, all bets are off, of course. But with such data you'd be in trouble regardless of what convoluted scheme you come up with.

I'd just discard any voxel that'd fall into this category and print an error, just as the texture loader currently does.

[DavidPH]

Sorry, it slipped my mind to make that very note that a new format without identification would be insane. And yes, a format that was able to identify itself would preclude the need for any external identification. When I wrote that, I was really mostly thinking of any other voxel formats that might already be out there.

If the two formats really are that unambiguously different (reading the spec from slab6 didn't leave me much insight either way on the matter, so I defer that point to you guys who have actually written stuff to do so), then I have no problem. My concern would be the convoluted nature of detection, but it's becoming pretty obvious to me that such concerns are unfounded. Besides, like Mancubus II said, you can't future-proof in any useful sense anyways, so if it works today, then that is good enough. Future-proofing tends to trip my over-thinking self up pretty badly.

Of course, I'm holding out for PNV. (I'm sure there will be a spec shortly after DoomScript is done.)

[Graf Zahl]

[quote="DavidPH"My concern would be the convoluted nature of detection,[/quote]


Have a look at the validation code for FPatchTexture to see what can all be done to check a file's sanity - and then at FTGATexture and FPCXTexture. All 3 formats have no real identifying marks but just looking for recognizable patterns is normally enough to distinguish them. KVX also has sufficient structure to check its validity. VOX on the other hand does not. All you can go for is checking if the size matches what it should be. Now, that may fail some broken files but since they are broken it wouldn't bother me much.

[randi]

Need I remind people that I made this post back in May when I discovered that somebody was actually making voxel models for Doom?

[StrikerMan780]

Just so everyone knows, it is INCREDIBLY easy to do pixel-perfect conversions from VOX to KVX, as Ken Silverman has provided tools for that, and I've used them. Now, I don't know if they are still on his site, you'll have to check. So if they are still there, and ZDoom doesn't support VOX, it's not that huge of a deal. (I'm also pretty sure you can just put the VOX files through SLAB6 and save them as KVX.)

[NeuralStunner]

Looking at the latest commit to the Voxel branch, and its naming system, I felt I should heckle express some concerns/opinions.

Why not a VoxInfo/VoxelDef lump? It could do several things:
- Apply a single voxel lump to multiple sprites.
- Set any rotation speed desired, simply use a negative number to rotate the opposite direction.
- Flip and rotate a voxel model to any orientation, so you're not restricted to the original fle's decision of what is "forward".
- A Translation system to pre-recolor a voxel, as you could when defining sprites in TEXTURES.

[Snarboo]

I think autodetection is fine, but I'm going to say something: at some point, modders will need specialized functions that voxels cannot do on their own. Things like translation, mirroring, flipping, attaching them to textures, etc. Why not expand the modeldef format that exists for 3D models to also cover voxel models? That way you have a universal lump that can be used by ZDoom and GZDoom. You could even toggle whether to use models or voxels depending on which port you are using.

[edward850]

- Apply a single voxel lump to multiple sprites.

You shouldn't need to. If you are already (re)creating decorate objects, you would just make the object reference the same frame.

- Set any rotation speed desired, simply use a negative number to rotate the opposite direction.
- Flip and rotate a voxel model to any orientation, so you're not restricted to the original fle's decision of what is "forward".

You already created the model, so why would you need to do that? Besides, wouldn't that be better off as part of [wiki]MODELDEF[/wiki]?

- A Translation system to pre-recolor a voxel, as you could when defining sprites in TEXTURES.

You mean this? Which you can already do? Because it's already there, you know, existing?

[NeuralStunner]

Egh, ACS. No thanks. (I'm talking about coloring sprites, not coloring entire actors.)

Placing it into ModelDef sounds okay, though.

[phi108]

If monster models are ever attempted in the future, I suppose the general appearance of the forward sprite takes priority of differences in other sprites? Like in this rough sprite edit, would the back of the voxel look somewhat like that? (minus the errors)



Though the error with walking animations is that the sprite depicts perspective differences between the front and back legs/arms (the leg sizes are screwed up in the edited back frame), so each leg should be the same size in the voxel model.

And I'm guessing where the feet connect with the floor should be modified to stand flat on the floor.

[Project Shadowcat]

phi108: That is completely up to the voxel builder to do.