Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Ghostpilot

Voxels (are they the future?)

Recommended Posts

RottKing said:

Well, I have a good amount of experience with the BUILD engine, I've made levels for Duke, Blood, and Shadow Warrior, so if you need my help I'll gladly help you.

That's good.
I'm just not really sure what I need help with...
I have trouble to define the problem.

My aim is to implement voxel support in a DooM engine.
It doesn't really matter if it's an existing motor, like ZDooM or something I make entirely myself from the DooM source.
But I was thinking of adding it to ZDooM and see if Randy wants to have it in the REAL ZDooM, otherwise I'll make my own version.
(Have in mind that this will be a S-L-O-W process that probably won't show any signs of life until the summer)

The problem is where to start.
I'm thinking of starting in the "wrong" end and try to understand how Ken's voxelformat works.
After that I can then backtrack my way through the buildengine code to find out how it was implemented.

It's probably not that hard to make it work.
But I want to make something userfriendly and good instead of working and semi-bad.
IF voxelsupport is added to doomport X, the following features should be there:
* Updating an old sprite skin wad with corresponding voxels should not require so much work.
(Maybe adding a few lines in the s_skin lump and then add the actuall voxelmodel(s).)
* Have a way of defining voxels for walldecorations. Like brambles, switches, lights...
* Anyone should be able to make their own voxelmodels easy.
(Therfore I would need to make a new version of Ken's outdated voxeleditor.)

Share this post


Link to post

Nice idea. I like the voxels in Shadow Warrior as well. I never played this game in 3dfx voodoo mode, as it looked amazingly ugly.

Concerning decorations, if you want all regular Doom switches etc. appear as voxels, it would be not that easy, as the switch graphics (ie. a completely different thing to sprite replacements) are placed in the TEXTURES lumps. The routine reading those lumps would have to place the voxel switches instead.

As for the monsters, it is probably best to stuck with md2 models as they do a good job and would be faster that way anyway.
Therefor voxel support would be best in a port, which already supports md2 models, and concentrate on decorations, imho.

Share this post


Link to post

I would tend to agree. Voxels arn't really suited to animated objects such as players/monsters.

Share this post


Link to post
DaniJ said:

I would tend to agree. Voxels arn't really suited to animated objects such as players/monsters.

That is partly why I want to do it.
I like to piss people off.
No... Seriously.
If I come up with some nice solotion to have one voxelmodel for each set of angels (like the playa1 to playa5) and
then correctly switch according to the pase of the animated sprites, I think it will look much better than both
the sprites AND Md2 models.

Md2 models are just TOO good looking for DooM.
DooM is oldschool and so should the objects ingame be also.
But that's my personal oppinion.

Adding volume to decorationsprites such as the wall climbing plant thing and the wall lamps would bring flat levels a new spark of life.
The hard thing will be to correctly allign the voxelmodel to the wall and make it stay there.

But the big problem for now, is that it's so damn hard and boring to make good looking voxelmodels.
The old slab6.exe editing program is too outdated and anti userfriendly for my taste.

I'll post about this issue on the Duke3D source forums as soon as I have time over to do that.
Maybe someone there allready has made a port of that old voxel editor. I seriously doubt that, but it's worth a try.

Share this post


Link to post
DaniJ said:

Very nice indeed. Looks EXACTLY like the Doom sprite.
Here is a pic of the Shellbox model used in the jDRP, so people can compare the merits of models v voxels.
http://modelyard.newdoom.com/jDRP/ShellBox.png

That shellbox model looks VERY VERY good, if I may say so.
How does it look ingame when used in JDooM?

ZDooM and JDooM are two totally different ports.
It's kind of hard to compare them on equal terms.
My statment that md2 models are too good looking
for DooM may apply to all ports except maybe JDooM.
But that doesn't mean that I take back what I have said... :-)

Share this post


Link to post

No, I totally agree. Models fit really well in jDoom because of all the other lighting/particle etc effects but in other ports without all the fancy effects they WILL look out of place.

Heh, I wasn't challenging you :-)

Now, I could put the actual sprite onto the texture without any smoothing/resampling/editing etc and it would VERY similar to your voxel model.

I think the real issue concerns whether people like seeing Doom in hires, or if they like the modeller's interpretation of the original sprites.

Share this post


Link to post

I think that voxels would be the choice sprite-replacement for engines/mods wanting to emulate the original doom style (basically and port in software mode). Its just like a sprite...yet you can completely circle it and see every angle.

Share this post


Link to post
iori said:

I think that voxels would be the choice sprite-replacement for engines/mods wanting to emulate the original doom style (basically and port in software mode). Its just like a sprite...yet you can completely circle it and see every angle.

My point exactly.

Share this post


Link to post

If you guys need help with Ken's tools, you might try emailing him. He is VERY responsive to emails, so its definitely worth a shot. The work so far looks nice!

Share this post


Link to post
Graf Zahl said:

And it's a perfect example why I don't like voxels!

Then please explain a little more.
I know it's blocky, but I kept it at original resolution to keep the old "uglyness" of DooM.
Keep in mind that the voxelmodel in that picture is zoomed in to like 700% of the real size.

Share this post


Link to post

I like the rocket. Just the gaps at top (and I presume at bottom as well) need to be filled in.
As it is not blockier than the original graphics, it's pretty much ok. I would definate use this, if they where available in the engine (providing it can be rendered fast enough)

As in that rocket screenshot, which is exactly based on the original images if I got this right, couldn't this be even done at run time, ie. implement such a converter in the engine? This way, it would even work with custom graphics.

Share this post


Link to post
LogicDeLuxe said:

As in that rocket screenshot, which is exactly based on the original images if I got this right, couldn't this be even done at run time, ie. implement such a converter in the engine? This way, it would even work with custom graphics.

It works in theory.
But as the tests with Slapspri.exe showed, the rotations need to be "perfect" for it to work propperly.
The DooM sprites and especially the player and monstersprites does not have perfect rotations.
That means that each rotation does NOT correspond to a imaginary voxelmodel in that rotation.
The result would be strange...

This method should work on cubic things as the medkits and such.
But those things is only one rotation (total 2D) in DooM.
So I guess I'm trapped at the old drawingboard for a while...

Share this post


Link to post

Just the gaps at top (and I presume at bottom as well) need to be filled in.

Doesn't that defeat the reason for using voxels? If you gonna start smoothing them over you might as well just use models.

The reason voxels are being disscused is because they would keep the same blocky, lowres look.

couldn't this be even done at run time, ie. implement such a converter in the engine? This way, it would even work with custom graphics.

AFAIK that would be damn near impossible.

Share this post


Link to post
Fredrik said:

The rocket will look a lot better without the stupid lighting.

I know. It's that damn voxel editing program that won't let me change the lighting.
If I could choose I would increase the light, so you could see what it's supposed to be...
But right now that's impossible.

I'll send a mail to the makers of that program and suggest improvments for the next version.
* A way to increase or decrease light levels.
* Support for .kvx files (Ken Silvermans voxel format)

Share this post


Link to post
DaniJ said:

Doesn't that defeat the reason for using voxels? If you gonna start smoothing them over you might as well just use models.

The reason voxels are being disscused is because they would keep the same blocky, lowres look.

I didn't talk about smoothing. A voxel is hollow, I know, but the rocket is a closed shape, and therefor there shouldn't any holes in it, when it becomes a voxel model. This wouldn't affect the blockiness, of course. It's more the completeness it affects.


In case you didn't notice yet, there are some more viewpoints of several sprites in the alpha versions of Doom, you can find in the archives in the historic directory. Maybe this comes in handy when constructing the voxels.

Share this post


Link to post
LogicDeLuxe said:

A voxel is hollow, I know, but the rocket is a closed shape, and therefor there shouldn't any holes in it, when it becomes a voxel model. This wouldn't affect the blockiness, of course. It's more the completeness it affects.

Huh? What do you mean?
I don't know wheather or not you are right about that.
It may depend on how you render the object.
I know that the voxel engines used for medical research, render the inerior of the voxel aswell, so you can chop the model into bits.

A voxel model in general isn't "hollow" until you render it.
Volume representation is all about representing volume, if you make the model hollow from the beginning you aren't representing volume anymore. When a voxel object is rendered the voxels that aren't visible at the moment aren't drawn. I'm not sure if I would call an object hollow just because you can't see the inside all the time.

I'm not really sure I follow how you think.
Can you try to explain what you meant in more detail?

Share this post


Link to post

Well, a voxel mustn't be hollow, and can be entirely solid. However they are hollow in case they are based on pictures showing the outer hull of the object they are displaying.
Also it wouldn't make any sense having parts inside, when you don't see them, as they are covered from the outer hull.
It's a matter of purpose, of course. Medical research isn't exactly a first person shooter. Voxels we are about to use are tiny solid objects, we can't see from inside under usual circumstances.
The voxels in Shadow Warrior are hollow as well. Although, you actually can see a key from inside, when its inserted into a lock. This is simply because the key is unatural big as many objecs are in such games for simplifying purpose, I think. They could had make the keys solid, I guess, but they probably thought this wasn't worth the effort.

Share this post


Link to post

I think your missunderstanding how voxels work.

Voxels are always hollow (by your analogy) because the outermost voxels are the only ones that are rendered.

In reality a voxel object is always solid, the renderer only displays individual voxels depending on whether they are vissible or not. All voxel objects are a solid block of voxels (a cuboid), it's the definition (a 3d data array) file that allows the renderer to decide which voxels are vissible and what colour they are. This is why voxels can be deformed (read partially destructable) as a copy of this array can be changed at runtime to hide/show individual voxels.

It's the renderer that decides wether an object appears hollow or not.

Share this post


Link to post
Guest
This topic is now closed to further replies.
×