[Jimmy]

If you need some code or something for the ball voxels, I should be able to help you.

Medkit: Looks pretty good.

+30 Medpack: I guess the shading is consistent with the sprite, but it comes off as too dark. I'd tone it down.

+10 Medpack: Looks good, though some pixels seem inconsistent on the sides.

NVG: Looks great!

Steroids: Looks decent; minor tweaking.

Pistol Magazine: Looks good, though some pixels seem inconsistent on the sides.

Pistol: Looks kinda strange, this one could benefit from some artistic liberties. I might draw up a sprite for you.

Box of Shotgun Shells: Needs some work. Outside is decent, but it needs some work. Think similar to this:
http://developer.valvesoftware.com/w/image...ox_buckshot.jpg
http://www.yosemitea...om/item195d.jpg
Me thinks the top of the box should be red and have the Remington bit on it.

Shotgun: Looks good from the front/back, but it could use some work in the parts not present in the sprite. Like the attention to detail with the ejection port.

Devastator Rockets: Very good, only needs some minor tweaking.

Tripbomb: Very nice, probably the best out of the bunch.

[ReaperMan]

Captain Awesome, on Feb 21 2011, 08:11 PM, said:

If you need some code or something for the ball voxels, I should be able to help you.

That would be appreciated.

Also fixed the steroids, small med-kit, pistol ammo, and Devastator ammo. I am going to leave the large med-kit as it is because i think it looks fine. I know its dark, but so is the sprite.

[bullerbullerseven]

Hi again.

I was thinking, are you working on an enemy model now? If not then i think it would be cool to see an enemy. If it's too much right now, maybe you could do the rocket?

[Danukem]

Enemies already have multiple sides, so they look 3Dish. Plus they are way harder to do than inanimate objects. Not only are they more complex, they also have a lot of animation, so a huge number of new voxels would be required.

So if I were ReaperMan, I would continue to focus on the easier stuff. The rocket is not a bad idea, though. I also think trees should be a high priority, since they look bad as sprites (they have that large sprite rotating with the player problem).

[bullerbullerseven]

I agree with DT.

If i may ask a question reaperman.

How long does it take you to make one voxels model.

[ReaperMan]

Jhect, on Feb 22 2011, 04:57 PM, said:

I was thinking, are you working on an enemy model now?

Didn't we talk about this before?

Jhect, on Feb 22 2011, 05:40 PM, said:

I agree with DT.

If i may ask a question reaperman.

How long does it take you to make one voxels model.

It depends on a number of things so i don't think i can really say.

[Hank]

Jhect, on Feb 21 2011, 07:59 AM, said:

Hmm i thought the originals rolled a lot faster...

You don't have to make new animations, you could just make the 2 pictures switch faster.

What you do to get this work is that you extract all the files but the duke3d.def into the duke folder. Instead of extracting the duke3d.def you simply copy the text in it and paste it into your orignal duke3d.def. There should already be some text in it.

Now you have two lines. The first allows HRP. The second allows VOXELS. To ignore one of them simply put // before the text.

Thanks. That did the trick.

@ The Reaper Man. Nice work.

[bullerbullerseven]

Hank, on Feb 23 2011, 03:24 AM, said:

Thanks. That did the trick.

@ The Reaper Man. Nice work.

Great.

The commander told me i was a noob because i used that method >.>

[The Commander]

Jhect, on Feb 24 2011, 06:36 AM, said:

Great.

The commander told me i was a noob because i used that method >.>

You are a n00b, you keep posting in peoples topics with statements that do not help them in anyway.
Your method takes more space up as was pointed out by several people.

ReaperMan, on Feb 22 2011, 07:35 AM, said:

Thats not trolling, its the truth. It is a waste of space.

[bullerbullerseven]

Obviously it wasn't helpless?

[Cravenmor]

Thanks to ReaperMan and others involved with Duke3D voxels. I ran the sample pack and was pleased with the results. IMO, voxels have an advantage of keeping the original game style while also enhancing it.

Only two things I noticed:

- yeah, the pistol seems to suffer some kind of low-resolution strangeness, as if the pixels are too big.

- also noticed turning on night vision does not illuminate voxels. Probably a normal thing due to the engine ignoring voxels for visual FX but still not sure where to post about it, and was not 100% sure if anyone else noticed yet.

Thanks and regards!

[Hank]

Jhect, on Feb 23 2011, 01:28 PM, said:

Obviously it wasn't helpless?

Yes, because of your post I noticed I had no Duke3d.def file in the duke directory I planted the voxles in. I have like eight Duke directories, and it's a mess. So thanks again.

[Hendricks266]

Unfortunately, it seems that you have created the majority of your voxels to face 90° away from the correct angle. This needs to be fixed in the voxel file, not maphacks. If a rotation feature is not in the voxel editor, bug Ken about it. Otherwise, the HRP maphacks should work once all its own rotation errors are fixed.

My edited version of _zoo.map, with all the pickup sprite angles corrected to face forwards, is available here.

[Hendricks266]

[Cravenmor]

Hendricks266, on Feb 23 2011, 08:02 PM, said:

Unfortunately, it seems that you have created the majority of your voxels to face 90° away from the correct angle.

I noticed this as well. One funny occurrence is the the beginning of E2L02 where the shotgun is revealed from the small door with a magical barrel longer than the cavity itself =D

Hopefully a rotation 90 degrees CW or CCW of the existing voxels is not a tremendous pain. Having voxels is the game nice either way.

[Scott_AW]

Thats an easy fix in slab6

you just use < and > to rotate and set orient to face in the options.

You can also adjust the pivots, where the model is centered. They behave like art in a way that you can offset them XYZ like you can offset a tile in an art file by XY

However a voxel is affected by both the tile's XY and its own.

[Hendricks266]

Failure loading voxel file "voxels/sprites/pickups/0060_keycard.kvx"
Error on line voxels/sprites/pickups.def:22.
Error on line voxels/sprites/pickups.def:22.
Error on line voxels/sprites/pickups.def:22.
Error on line voxels/sprites/pickups.def:22: expecting '{'
Error on line voxels/sprites/pickups.def:22.

"voxels/sprites/pickups/0060_keycard.kvx" does not exist.

Also, organize your defs in increasing tile number order.

[ReaperMan]

I fixed the orientation of all the voxels and did some more editing so they would look better. Also i added some switches.

[ReaperMan]

Here is a more up to date version of the voxel pack, several things have been added and i included the maphacks from the HRP to fix some of the more obvious problems.

[Scott_AW]

Its looking good, except the gray switch with the yellow toggle, is backwards and going into the wall instead of sticking out.

Wait, its actually a problem with the original Duke3d map, I found its correct in other places, just not under the counter in the movie theater.

[ReaperMan]

Scott_AW, on Mar 5 2011, 05:20 PM, said:

Its looking good, except the gray switch with the yellow toggle, is backwards and going into the wall instead of sticking out.

Wait, its actually a problem with the original Duke3d map, I found its correct in other places, just not under the counter in the movie theater.

Um thats a secret, thats why its backwards.

[Scott_AW]

LOL, good enough.

I like how its looking though, how far are you going with this? I noticed a lot of decor objects are pretty low-res to begin with and should be easy to convert.

Also the best way to address sizing issues with voxels when going to 32bit mode is CON coding, using sizeat. Polymost ignores the scaling defined by DEF

[Hendricks266]

Good update! All rotation errors have been fixed.

Scott_AW, on Mar 5 2011, 03:31 PM, said:

Also the best way to address sizing issues with voxels when going to 32bit mode is CON coding, using sizeat. Polymost ignores the scaling defined by DEF

No, it's not. That's a problem with Polymost, and it should be fixed in Polymost.

[Scott_AW]

I wasn't aware you fixed it, my bad. I just recall it from when I first was playing around with it.

[Hendricks266]

Not sure exactly what you're referring to, but it's not fixed. What I'm saying is that CON coding is not "the best way to address sizing issues with voxels when going to 32bit".

[Scott_AW]

When defining a voxel model you can set its scale, like 0.5, 1.0, 1.5 and such to set how big it renders, I noticed it didn't translate for things like floor tiles that had to be expanded to 1.25 for some reason, despite being 32pixels like my standard texture tile.

One monster based off of pigcop scales properly, one I made custom does not in 32bit mode, it has no sizeat code and pigcops are hardcoded to size to 80 I believe.

That and scaling of sprites I do in build sticks in 32bit mode. Its just the DEF part of scaling that seems to get ignored.

[Micky C]

I just downloaded this and tried it out for the first time, and I was blown away! This is truly amazing work you're doing, I can't believe how good yet authentic the voxels look. They fit in perfectly with the game, I wish you all the best with the rest of this project.

[Gambini]

I tested it and looks awesome. Here are my two cents:

-The shells box is a little bit bigger than it should be.
-The #164 switch has to be wider, and the led color seems to be the wrong one because it doesnt stand out at distance (you know that red color the pigcops eyes use, which doesnt fade off with shading nor vis)
-The #130 lock (and problably the other one too) has to be wider.

Also in general their lighting seems to be a little brighter/darker depending on the object.

[Jan Satcitananda]

The problem with switches is that in case of voxels they get the same aspect ratio correction as regular facing sprites (specifically, horizontal narrowing). To counteract this, one has to make maphacks or scripts which multiply xrepeats of wall-aligned voxel objects by 1.2.

[Danukem]

CraigFatman, on Mar 6 2011, 09:16 AM, said:

The problem with switches is that in case of voxels they get the same aspect ratio correction as regular facing sprites (specifically, horizontal narrowing). To counteract this, one has to make maphacks or scripts which multiply xrepeats of wall-aligned voxel objects by 1.2.

But since switches are almost always wall-aligned, wouldn't it be better to just make the voxel wider?