I remember seeing rendering glitches elsewhere besides in this example, but this one I do remember:
Savegame DL: https://www.dropbox.com/s/itx8ij6yfwwjf ... dsave?dl=0
It's in Duke E3L4 (L.A. Rumble). You have to look through the blue keycard door while at the same time aiming slightly up. (The savegame should open with the correct aiming angle.) The area inside the door isn't rendering correctly and is displaying a HoM effect.
If you can't reproduce it, I can provide a screenshot. I'm playing with OpenGL and a Radeon Vega 64.
[0.7.1 DUKE] HoM effect in certain places
Moderator: Raze Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
-
- Posts: 42
- Joined: Sun Apr 14, 2019 1:11 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
- Location: Finland
-
- Posts: 506
- Joined: Mon Mar 28, 2011 1:56 am
Re: [0.7.1 DUKE] HoM effect in certain places
I noticed this, too. I forgot to save/screenshot but I think it was near the endlevel switch of E1L1, standing on the little bridge, looking into the corridor. I guess some RoR glitch.
EDIT: Less noticeable glitch exists in RedNukem at the same place.
EDIT: Less noticeable glitch exists in RedNukem at the same place.
-
- Posts: 1349
- Joined: Tue Nov 05, 2019 6:48 am
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
Re: [0.7.1 DUKE] HoM effect in certain places
Yeah, basically this, I believe.VGA wrote:I noticed this, too. I forgot to save/screenshot but I think it was near the endlevel switch of E1L1, standing on the little bridge, looking into the corridor. I guess some RoR glitch.
EDIT: Less noticeable glitch exists in RedNukem at the same place.
Must be some ROR shenanigans at play since the way the render handles them is... suboptimal and depending on the position and angle, it can cause them to HOM. There's plenty of occasions in SW where this may be observed, such as a rooftop in Twin Dragon's... Emergency Room? And Skyline in Wanton, at various windows.
-
- Lead GZDoom+Raze Developer
- Posts: 49193
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [0.7.1 DUKE] HoM effect in certain places
Another good HOM is in RRRA where you can jump through a hole in the floor (can't remember which map right now) from the top it looks all fine but from the bottom it's a HON glitchfest.
All these portals were done really poorly. with basically zero consistency checks present. Thinking about how much effort it was to get GZDoom's portal to render properly it's not really surprising that these do not work 100% reliably, especially when using a renderer as weird as Polymost which does its best to work around all the features a decent graphics card has.
All these portals were done really poorly. with basically zero consistency checks present. Thinking about how much effort it was to get GZDoom's portal to render properly it's not really surprising that these do not work 100% reliably, especially when using a renderer as weird as Polymost which does its best to work around all the features a decent graphics card has.
-
- Lead GZDoom+Raze Developer
- Posts: 49193
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [0.7.1 DUKE] HoM effect in certain places
I can confirm the HOM but this is something that requires a new renderer to be fixed. Apparently Polymost is a bit too aggressive when culling invisible sectors.
-
- Lead GZDoom+Raze Developer
- Posts: 49193
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [0.7.1 DUKE] HoM effect in certain places
Putting a note here for all the reports I moved to "on hold" today.
All of these issues are inherent to how Polymost works. They cannot and will not be addressed with the current render code, but will of course be taken into consideration when developing a new renderer starts.
All of these issues are inherent to how Polymost works. They cannot and will not be addressed with the current render code, but will of course be taken into consideration when developing a new renderer starts.