[Borion]

faucet (574, 670, 671)


EDIT:
Handles don't turn when water runs as on original sprite.

[NightFright]

Uploaded to GitHub. I have unlocked the animdefs line for the running water tap (#670/671) that had been commented out since #671 had been missing until now, but I wasn't able to test it by myself. Please check and see if it looks OK.

[Striker]

But there already was a faucet voxel, with animation too? (Which I submitted earlier)

[NightFright]

Updated Borion's foodobjects on GitHub (color fixes for 4540-4542, remade 4546-4548, 4569).

[Borion]

Striker, on 10 April 2020 - 12:28 PM, said:

But there already was a faucet voxel, with animation too? (Which I submitted earlier)

There was problem with cranes length and sides needed some touchups. "Frankensteining" fixes was more work than making it from scratch, it is not a sneaky way of replacing other peoples contributions (if anyone wonders).

[Borion]

Not eternal after all

Spacemarine (1353)


EDIT:
It has no elbow pad on purpose, looks better without it.

[OpenMaw]

Borion, on 10 April 2020 - 01:50 AM, said:

Yes, Phredreeke. They tempt me since I played N64 version for the first time last year.

But first I want to finish most jarring omissions in VP (box of donuts, broom, mop, chair3, firevase...etc.). I'm getting there.

You really are. You have been hauling the mail, dude. Great, great work. You're blowing the HRP out of the water. This is far more aesthetically pleasing than anything we've had in this community in years.

Striker, on 10 April 2020 - 12:28 PM, said:

But there already was a faucet voxel, with animation too? (Which I submitted earlier)

I meant to mark you up, sorry Stryker.

[Borion]

Commando Nukem, on 11 April 2020 - 07:47 AM, said:

You really are. You have been hauling the mail, dude. Great, great work. You're blowing the HRP out of the water. This is far more aesthetically pleasing than anything we've had in this community in years.



I meant to mark you up, sorry Stryker.

I don't even know what to say...Thank You!!!

Being part of this community is something special for me, hard to describe how and why...just know folks that your appreciation is not making me conceited, it "just" helps a lot

[NightFright]

Space Marine (tile #1353) on GitHub.

[NightFright]

LeoD brought it to my attention that the new foodobjects are in the wrong folder on GitHub. I'll get that fixed ASAP.

[Borion]

Donuts (1045)

[NightFright]

And it's on GitHub already.

[Borion]

Meter3 (0918)

[NightFright]

Now on GitHub, too.

[Fox]

Borion, on 07 April 2020 - 06:00 AM, said:

Antena (0607-0608)

May I ask, why do some voxels often look much brighter than the sprites?

[Borion]

Fox, on 14 April 2020 - 11:14 AM, said:

May I ask, why do some voxels often look much brighter than the sprites?

You mean gifs? Because I brighten rotating voxel part, so they look less muddy on the edges when viewed in non-native resolution. Jagged voxel edges on grey background tend to look less than perfect when scaled down.
About voxel KVX models, in most cases they use exact palette of each original sprite (subset of DN3D palette). Sometimes I add some extra colours, if it helps but not goes too far from original (at least thats the idea) but even then its still 90% of original sprite.

If You ask about fact, that shadows are often much softer comparing to sprites, there is a reason for that. Flat sprites need illustration/drawing tricks (like deep shadow) to fool mind into thinking they got some depth. They always rotate to face viewer so this trick works. But If I would copy same strong shadowing to voxels, it would look very bad in most cases. There would be discrepancy between environmental light direction and the way object is lit.
In case of Antena, I made it a bit brighter so it is more shiny/metalic than sprite. It looked like grey plastic model without those very deep shadows.

Now that you ask about it Fox, I think I might overdid it in case of antena.

EDIT: typos

[NightFright]

Can anyone tell me whether neon1 (cinema sign, tile #925) is used in any other official Duke3D map (or addons) other than E1L1? Borion made a new voxel, but it seems old maphacks are not accurate. There's also neon2 (#926), but it seems it's not used in official maps.

[LeoD]

NightFright, on 15 April 2020 - 11:26 AM, said:

Can anyone tell me whether neon1 (cinema sign, tile #925) is used in any other official Duke3D map (or addons) other than E1L1? Borion made a new voxel, but it seems old maphacks are not accurate. There's also neon2 (#926), but it seems it's not used in official maps.

Rooma Loom's GRP Viewer helps. I've put all official maps (D3D, DC, VACA, NW, WT) into one GRP and did a search. #0925 also shows up in NW2 (of course). No further sightings of #0925/#0926. I didn't check other palettes than pal0, though. Note that the #0925 HRP model is rotated by 90° for whatever reason.

However, the maphack for sprite 348 is still wrong, indeed. Should be angoff -512. Borion's #0925 voxels shouldn't need maphacks in E1L1/NW2.

[EDIT:]Hm, maybe the sprite #348 hack isn't that wrong after all. The mapper's decision to make that sign readable from both sides by adding a second one-sided sprite (#348), turned by 180°, doesn't match a real world neon sign (tubes). That's why I had rotated the #348 md3 to match #399. (I could have moved it to infinity as an alternative.)
I'd therefore recommend "sprite 348 angoff 1024 // tile0925 neon1 (cinema)" for the voxel model, and no hack for #399.

[Mark]

LeoD Can you make a rough guess on how many HRP models are either not centered or rotated properly when created? Just curious. I suppose since all the work has gone into maphacks over the years it would not be desirable to correct them this late in the game.

[NightFright]

Well, according to Borion, the neon1 voxel is off by 45 degrees in E1L1. He hasn't published it here yet, so you guys can't verify it.

Anyway, if just two maps are concerned, I guess the needed effort for maphacks adjustment is minimal.

[NightFright]

Update:
Neon1+neon2 (#925+926) added to GitHub. Maphacks for E1L1 and NW2 updated.

@LeoD:
Thanks for the research! I had been using RomaLoom's tool for the longest time before switching completely to SLADE for convenience. Unfortunately it can't do that tile search for maps. Time for a feature request, possibly.

[LeoD]

Mark, on 15 April 2020 - 06:08 PM, said:

LeoD Can you make a rough guess on how many HRP models are either not centered or rotated properly when created? Just curious.

The last section of hrp_todo.txt has an incomplete list of items I've come across (about 50). Then there are more bottles, and boxes (ammo, donuts) with some of their contents outside: the modellers chose their origin in the centre of the box (maybe HRP policy back then), whereas the voxels' origins are the actual centre of the sprite image. I guess that 80-120 models may be affected in total, depending on how close you look...
The current VoxelPack repo has 283 KVX files, my Voxels4Maphacks project has 63 'backported' KVX so far, plus a few scale entries in the DEFs. Extreme nitpicking involved at times, though. This work has led to rescaling some models in the HRP as well.

Mark, on 15 April 2020 - 06:08 PM, said:

I suppose since all the work has gone into maphacks over the years it would not be desirable to correct them this late in the game.

Not for me, definitely. But since HRP r722 the maphacks are well suited for scripted patching of this type of issues.
But: all not maphacked model instances which looked OK so far would then look off after angle/offset correction -> their sprite numbers then need to be extracted from the MAP files and have adaptive hacks (auto-)added to the MHKs.
That's why I've decided to go the pragmatic route first: Voxels4Maphacks.
In addition I've made an EDuke32 patch which translates/recalculates pitch/roll+md[x|y|z]off maphack tokens to the recently introduced mdpos[x|y|z]off movements. (HRP/UserMapHacks r722 or later required)
Other than tilting on sloped surfaces, voxels should now be 99% on par with md3 models, maphack wise. No voxel-specific maphacks required. Needs more testing outside of my workshop, though.

[brullov]

Borion, on 14 April 2020 - 07:08 AM, said:

Meter3 (0918)

You have just made a few hundred hours spent in mapster32 useless. Great job anyway, can't wait to see more

[NightFright]

Don't tell me you wanted to model a fuse box like that in Build as a level structure... o.O

[Striker]

I have a request for a voxel: The Tripmine. (The one you plant on the wall, not the pickup)

[LeoD]

Striker, on 16 April 2020 - 11:14 AM, said:

I have a request for a voxel: The Tripmine. (The one you plant on the wall, not the pickup)

voxel "voxels/pickups/0027_tripbomb.kvx" { tile  2566 scale 4.0 }

Done.

[Borion]

brullov, on 16 April 2020 - 09:27 AM, said:

You have just made a few hundred hours spent in mapster32 useless. Great job anyway, can't wait to see more

No more sleepless nights spent making sprite-pancakes
Thanks

Striker, on 16 April 2020 - 11:14 AM, said:

I have a request for a voxel: The Tripmine. (The one you plant on the wall, not the pickup)

LeoD, on 16 April 2020 - 01:26 PM, said:

voxel "voxels/pickups/0027_tripbomb.kvx" { tile  2566 scale 4.0 }

Done.

Sure, Striker.
Thanks Leo, but 0027 has very low resolution comparing to 2566.

[Borion]

[Kyanos]

Hate to off topic... got a quick question Borion. Do you know a way to join two voxels together? I have an animated voxel and I want to make some changes to the static part but then copy-paste-merge it into the animation frames if you get my drift.

[Borion]

Photonic, on 16 April 2020 - 04:40 PM, said:

Hate to off topic... got a quick question Borion. Do you know a way to join two voxels together? I have an animated voxel and I want to make some changes to the static part but then copy-paste-merge it into the animation frames if you get my drift.

With Goxel it would go like this. Import frames as separate layers. Be sure to create new layer & select it before importing each frame. Now import your separate edited part also on a new layer. Now for every frame make separate copy of this edited part, so they are paired. After that use layer visibility (eye icons) and 'merge visible' functions to merge each pair (frame+modified part). When exporting to KVX also turn visibility only for layer/frame that you are exporting. I hope I'm clear, I'm very sleepy. If you will have any problems Photonic PM me tomorrow.

Cheers

EDIT:
KVX files exported from Goxel absolutely need to be imported to SLAB6, re-palletised with palette.dat & exported as KVX (5 Mips). Otherwise colour index have completely screwed up colours order.