[jkas789]

Look, as a voxel fanatic I'm just happy my favorite games are getting the voxel treatment. Duke 3D, Blood, Powerslave, Shadow Warrior. Even Redneck Rampage got voxel love via Redneck redemption.

The fact that they look fucking good is just a plus. A big magnificent throbbing plus.

[Danukem]

One-sided sprites are not supposed to be rendered from the other side, and that fact is taken advantage of extensively in maps to hide hidden switches. Unfortunately, voxels do not obey this rule in Eduke32, which means that the switch voxels break most maps (or at least are an ugly blight on them since you see the big backside of a voxel where there is supposed to be a secret switch).

I've had to remove switch voxels in my current project for this reason, because editing or maphacking all the maps is not an option (I can explain why but let's just accept that it's not an option).

Has anyone got a solution?

[NightFright]

The only way would probably be if EDuke32 automatically suppressed voxel rendering for one-sided sprites or if they added an easy way via a drop-in def or con file doing the same.

[Danukem]

NightFright, on 26 November 2020 - 12:58 PM, said:

The only way would probably be if EDuke32 automatically suppressed voxel rendering for one-sided sprites or if they added an easy way via a drop-in def or con file doing the same.

I decided to try a CON hack. So far it seems to work.

appendevent EVENT_GAME
switch sprite[].picnum
case SLOTDOOR case 133
case SPACEDOORSWITCH case 137
case SPACELIGHTSWITCH case 139
case FRANKENSTINESWITCH case 141
case DIPSWITCH2 case 165
        ifand sprite[].cstat 64
        {
                ifangdiffl 532
                        cstator 32768
                else
                ifand sprite[].cstat 32768
                        cstat 80
        }
        
break
endswitch

That doesn't cover every type of switch but it's the ones I have seen used on secrets.

EDIT: Nevermind, that will make some switches invisible that are supposed to be visible. I'll leave the post here in case it leads to something useful.
EDIT2: Better now, just had the wrong angle number.

[Phredreeke]

Danukem, on 26 November 2020 - 12:46 PM, said:

One-sided sprites are not supposed to be rendered from the other side, and that fact is taken advantage of extensively in maps to hide hidden switches. Unfortunately, voxels do not obey this rule in Eduke32, which means that the switch voxels break most maps

That's very interesting given we've had the opposite experience with Shadow Warrior.

There's a level in Twin Dragon where a keycard is incorrectly set as a one-sided sprite. In the DOS game as well as Redux the voxel is seen regardless. In VoidSW and BuildGDX the voxel could only be seen from the visible side. GDX later added a maphack for the key.

[Borion]

Sprite 480
Wasn't sure if it suppose to be some kind of energy weapon or astronomical observatory. I kept original light, so warm sun light from one side and cold moon light from the other. I think it makes sense in this case as it is space themed object.

Preview:

[Striker]

It's a telescope station, like such:

[Jimmy]

Phredreeke, on 26 November 2020 - 01:50 PM, said:

That's very interesting given we've had the opposite experience with Shadow Warrior.

There's a level in Twin Dragon where a keycard is incorrectly set as a one-sided sprite. In the DOS game as well as Redux the voxel is seen regardless. In VoidSW and BuildGDX the voxel could only be seen from the visible side. GDX later added a maphack for the key.

SW had voxel switches, so I'm sure there's some hardcoded voodoo at work.

[Dzierzan]

Nice, I also started the telescope, but I didn't go far. Please, don't do the space shuttle, I am 50% done!

[jkas789]

Jesus fucking Christ! What is this? The year of Build games Voxel renaissance? Some really high quality voxels have been coming in across the board. (⊙_⊙)

[NightFright]

Considering all these contributions and looking at the changelog compared to v1.2, I think the final v1.3 release rather needs to be labelled v2.0. We already went far beyond what was the necessary goal for a new 1.x version... Basically we just wanted all pickups complete and now it's hundreds of voxels on top of that. Which is excellent, of course.

[NightFright]

Observatory added on Github. The voxel is so good I had to look twice to make sure it wasn't the sprite still.

[Dzierzan]

When you look at missing voxels, not much has left for Duke Nukem 3D. Of course when looking at 4 episodes without 5th one.

[NightFright]

I think we are also still missing Vacation voxels. However, we still haven't found a user-friendly method to activate them without con/def editing.

[Phredreeke]

NightFright, on 28 November 2020 - 10:01 AM, said:

I think we are also still missing Vacation voxels. However, we still haven't found a user-friendly method to activate them without con/def editing.

For the upscale pack I've used a batch script that lets the user pick expansion and then loads the appropriate DEF file. It works but looks extremely plain - would be nicer to have a GUI for it

[Dzierzan]

Maphacks for these voxels could be applied here:



Or here too:



Were any maphacks applied to the spacesuit?

[NightFright]

I would assume so. If voxel rotations are different from the HRP models, maphacks would be off. That or something broke with maphacks functionality in EDuke32. (I wouldn't be surprised of the latter, I've had quite some issues getting the pitch command to work lately, for instance.)

I think eventually someone's gonna have to go through all Duke3D maps again with voxels and see which maphacks still work and which don't. HRP and voxel pack maphacks are drifting more and more apart. But before, we should check if EDuke32 is still handling all maphacks commands properly.

[Striker]

You cannot pitch voxels, thus the pitch command will not work for them.

[jkas789]

NightFright, on 28 November 2020 - 10:01 AM, said:

I think we are also still missing Vacation voxels. However, we still haven't found a user-friendly method to activate them without con/def editing.

Honestly as an end user I think the minimum one has to learn to mod Build games is def file editing. So I wouldn't worry too much about that.

It would be nice if eduke32 could load voxels when it detects a group file though.

[NightFright]

Striker, on 28 November 2020 - 05:01 PM, said:

You cannot pitch voxels, thus the pitch command will not work for them.

Ok, in that case, a whole lot of maphacks are useless. If I understood correctly, mdxoff/mdyoff/mdzoff only work after a pitch (or roll) cmd has been used. If neither pitch nor roll can be used, you can forget about moving a voxel up/down, to the side or forward/backward. That wouldn't leave many repositioning options, actually.

Which ones actually DO work? Angoff and notmd?

[Striker]

NightFright, on 29 November 2020 - 12:37 AM, said:

Ok, in that case, a whole lot of maphacks are useless. If I understood correctly, mdxoff/mdyoff/mdzoff only work after a pitch (or roll) cmd has been used. If neither pitch nor roll can be used, you can forget about moving a voxel up/down, to the side or forward/backward. That wouldn't leave many repositioning options, actually.

Which ones actually DO work? Angoff and notmd?

The offsets don't need a pitch or roll command to function (at least, they shouldn't if I recall), but it does control the center of rotation/pitch.

[NightFright]

Well, if you look at the maphacks, they often (if not always) do things like pitch -1 or roll -1 before any mdx/y/zoff entry. I think someone once said it doesn't work without that.

Anyway, I never managed to do anything besides angoff adjustments successfully. The rest seems to be some rocket science I fail to comprehend.

[Phredreeke]

Are you sure those aren't just the order of operations?

[Striker]

NightFright, on 29 November 2020 - 02:29 AM, said:

Well, if you look at the maphacks, they often (if not always) do things like pitch -1 or roll -1 before any mdx/y/zoff entry. I think someone once said it doesn't work without that.

Anyway, I never managed to do anything besides angoff adjustments successfully. The rest seems to be some rocket science I fail to comprehend.

If they're in map units, the values probably need to be rather large to have a visible effect.

[NightFright]

I guess I need to use a test map with just one voxel and mess with the maphacks for it to see what's the actual effect.

[0815Jack]

Dzierzan, on 28 November 2020 - 09:50 AM, said:

When you look at missing voxels, not much has left for Duke Nukem 3D. Of course when looking at 4 episodes without 5th one.

yeah looks pretty complete except for episode 4..... and it depens if someone is gonna make voxels for the satellite, radar dish, reactor core, monk, lawyer etc


years ago I made a map for testing all the hires-stuff..... not beautiful but it does the job.... (it could also contain none used stuff)

Attached File(s)

•  HRP-TEST.zip (10.02K)
  Number of downloads: 241

[Borion]

0815Jack, on 29 November 2020 - 09:44 AM, said:

yeah looks pretty complete except for episode 4..... and it depens if someone is gonna make voxels for the satellite, radar dish, reactor core, monk, lawyer etc


years ago I made a map for testing all the hires-stuff..... not beautiful but it does the job.... (it could also contain none used stuff)

Thanks for map Jack, nice to have all that stuff in one place.
Regarding stuff that you mentioned, I'm working on satellite (dish) and radar dish at the moment. As You can see couple posts earlier Dzierzan is working on space shuttle. So we are filling remaining gaps, give it some time and hopefully all will be done.

On the subject of stuff that wait to be done, there are couple objects that go beyond KVX file format limitation of 255x255x255 voxels. I'm wondering what to do about them.
Is it technically possible to "attach" two models to one object, so we could stick two KVX files together? Anyone knows?

[Dzierzan]

Yeah, it's a useful map, you can nicely spot what's still missing. And you can notice different quality of voxels, considering a lot of people were contributing to this project.



This table could use some polishment like removing standing out voxels and remove original shading on sides (at least soften that).



Similar situation.

Well, I should update my pipes too, since I did the same mistake and later Borion gave me hints what I should be avoiding.

[ReaperMan]

NightFright, on 27 November 2020 - 06:22 AM, said:

Considering all these contributions and looking at the changelog compared to v1.2, I think the final v1.3 release rather needs to be labelled v2.0. We already went far beyond what was the necessary goal for a new 1.x version... Basically we just wanted all pickups complete and now it's hundreds of voxels on top of that. Which is excellent, of course.

Yes I think we have surpassed version 1, that was supposed to be pickups only. I think we are officially in version 2.

[0815Jack]

Borion, on 29 November 2020 - 10:59 AM, said:

Thanks for map Jack, nice to have all that stuff in one place.
Regarding stuff that you mentioned, I'm working on satellite (dish) and radar dish at the moment. As You can see couple posts earlier Dzierzan is working on space shuttle. So we are filling remaining gaps, give it some time and hopefully all will be done.

Dzierzan, on 29 November 2020 - 11:37 AM, said:

Yeah, it's a useful map, you can nicely spot what's still missing. And you can notice different quality of voxels, considering a lot of people were contributing to this project.

I'm glad that I could help Looking forward to your next stuff