Problem with Transfer_Heights

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom 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.
Gez
 
 
Posts: 17943
Joined: Fri Jul 06, 2007 3:22 pm

Problem with Transfer_Heights

Post by Gez »

[wiki=User:Koverhbarc]Someone[/wiki] decided to use the wiki instead of filing a proper bug report. So for reference I'm putting this here instead.

Here is the report:
Use of this function to create 3D effects is supposed to work but in reality has one or more bugs. This test map I created, [wiki]File:Testk.7z[/wiki], with the modifications I describe, demonstrates this occurrence. Note that the ground floor has a below-floor area adjoining a normal area, and exhibits no HOM, and also the passage between the demon's room and the invisible floor is a below-floor area between two normal areas, and shows no HOM. On the contrary, the stairway shows HOM (viewed from the stairs into the main room) on both the second and third floors, where one is looking resp. from a below-floor to a normal area and from a normal to an above-ceiling one; the other direction shows a solid wall (incorrectly). The passage on the third floor to the imp's room is interesting, as in the configuration it is in now, with all above-ceiling areas, it shows HOM when looking out from the main room, but only if one looks across all three lines dividing the two room (or both before I made the middle one). In a configuration where the imp's room, or that room and the hallway, are made normal sectors, the HOM shows up in the reverse direction only, and at the spot where one is looking from the normal to the above-ceiling area; the same is true in the right-hand room on the third floor if it is modified. Yet the staircase shows that it is not restricted to that case. Finally, there is currently a HOM from the demon's room back into the main room, though that shows up only when standing back of the diagonal line joining the slopes, and can also be seen in the mirror. Along this path there is only normal areas, and it showed up only when I constructed that room passing above and south of it, which should not affect it at all. This suggest a node-builder error, but when I removed the nodes from the wad (allowing my ZDoom (the latest version) to use its own node-builder), it did not change.

Therefore, there seem to be two problems with the 3D effects: one sometimes causing HOM when looking between areas with different height-transfer status, and one that can affect unrelated areas, probably due to the nodes being screwed up. Further these problems seem more likely to occur with fake ceilings than with fake floors, as when the center block (between the two ground-floor rooms) is elevated to the fake-ceiling region, it does show HOM at the usual spot. This proves a bug, as fake floors and fake ceilings should be treated exactly the same by the renderer. This is not an invariable rule though as even when my test map is edited to remove the whole third story and all use of false ceilings, the bug on the stairs remains; however, it must apply in normal situations, because many test and production levels have used the technique with false floors to produce 3D geometry.

A second issue related to 3D shown by my test level is that the lift in the main room, when it rises above the fake floor, becomes invisible. More generally, a real floor or ceiling can't move through a fake floor or ceiling and be rendered properly. This isn't technically a bug, since it is intended behavior, but it it rather pointless since the invisible-floor effect it was meant to create (in Boom) is rare and now more easily handled by the bridge thing. I can't see why the renderer couldn't recognise which section the lift (etc.) is in now and render it there, and the old behavior if really needed still emulated for compatibility.

Finally, although possibly not related, another bug shown by my demonstration relates to the teleporter line. If you can activate it from the upper level you can get stuck in a wall, though it may take some trying to reproduce this.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49230
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Problem with Transfer_Heights

Post by Graf Zahl »

Ouch.

Talk about feature abuse! This is not a bug but only some fundamental misunderstanding of what this feature does. It is not possible to look from a lower part into the normal part without getting HOMs and this is nothing that can be changed.

Transfer_Heights was never meant for fake ROR effects.

And the teleporter line: Of course you can get stuck in a wall if you define it in a way that you can get teleported into a position where you end up in a wall! Simple mapping error.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49230
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Problem with Transfer_Heights

Post by Graf Zahl »

I added a description of this limitation to the Wiki page - but in a way that it doesn't get lost in such a wall of text.
User avatar
Project Shadowcat
Posts: 9369
Joined: Thu Jul 14, 2005 8:33 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support
Location: Blacksburg, SC USA
Contact:

Re: Problem with Transfer_Heights

Post by Project Shadowcat »

Graf Zahl wrote:Transfer_Heights was never meant for fake ROR effects.
Oh dear. :(
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49230
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Problem with Transfer_Heights

Post by Graf Zahl »

Why "Oh, dear."? I think any detailed description of how it works should make that abundantly clear.

You can fake some stuff but it'll always be very limited.
User avatar
Project Shadowcat
Posts: 9369
Joined: Thu Jul 14, 2005 8:33 pm
Preferred Pronouns: They/Them
Operating System Version (Optional): Windows 11
Graphics Processor: nVidia with Vulkan support
Location: Blacksburg, SC USA
Contact:

Re: Problem with Transfer_Heights

Post by Project Shadowcat »

I've said it before, and I'll say it again, what is clear to you, because you're a dev, is not clear to us, as simple modders without knowledge of the code.
I'll find another way for what I'm doing in the meantime.
Guest

Re: Problem with Transfer_Heights

Post by Guest »

What definition of ROR are you guys using here? Super Sonic Doom (and LTSD for that matter) use Transfer_Heights for ROR effects with Bridge Things pretty well...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49230
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Problem with Transfer_Heights

Post by Graf Zahl »

If you mean 'glitches just if you look from the right spot' you are correct.
User avatar
Xaser
 
 
Posts: 10774
Joined: Sun Jul 20, 2003 12:15 pm
Contact:

Re: Problem with Transfer_Heights

Post by Xaser »

There's nothing wrong at all with using it in such a way if the limitations are kept in mind, which SSD did (though the doors looked very, very silly -- the texture could've at least been changed :P ).
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49230
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Problem with Transfer_Heights

Post by Graf Zahl »

The bigger problem with SSD were the hideous skybox windows anyway.,,
User avatar
Xaser
 
 
Posts: 10774
Joined: Sun Jul 20, 2003 12:15 pm
Contact:

Re: Problem with Transfer_Heights

Post by Xaser »

They look fine if you maneuver yourself into the correct position and don't move. :P

[Fun fact: during the boat launching sequence in Serpent: Resurrection, I was very impressed with the effect when the boat was pulling away from the dock... until I made the mistake of moving and spoiling the skybox-ness. :P ]
Guest

Re: Problem with Transfer_Heights

Post by Guest »

OK, thanks for looking at my wad. You seem to have determined the error and the explanation you provided seems to work. I still think that it is a bug, or at least something that could be easily fixed, that viewing from a normal sector works only for false floors and not for false ceilings - as I said, they should use the same code.

You're also right about the teleporter line, now that I think about it.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49230
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Problem with Transfer_Heights

Post by Graf Zahl »

Betsy Senningtock wrote: or at least something that could be easily fixed,

No, it isn't. The entire lower/middle/upper separation is global, i.e. if you once look into a lower sector it is set for the current frame and cannot be changed afterward for other sectors. So you won't be able to see middle and upper parts elsewhere. This is how the Boom team designed it 12+ years ago and it's really the only way to handle the feature. ZDoom is already more flexible by allowing to see into lower parts from non-Transfer_Height sectors but this already needs some hacks directly in the renderer to work. Imagine what this might produce if it has to be done per sector.
koverhbarc
Posts: 230
Joined: Mon Dec 06, 2010 6:26 am

Re: Problem with Transfer_Heights

Post by koverhbarc »

First, why does this board change my username to 'Betsy Senningtock'? Whose cruel joke is that (I am male)? I registered under my usual handle.
Graf Zahl wrote:No, it isn't. The entire lower/middle/upper separation is global, i.e. if you once look into a lower sector it is set for the current frame and cannot be changed afterward for other sectors. So you won't be able to see middle and upper parts elsewhere. This is how the Boom team designed it 12+ years ago and it's really the only way to handle the feature. ZDoom is already more flexible by allowing to see into lower parts from non-Transfer_Height sectors
I said, to allow this feature (only) for upper parts as well as lower and middle. I can't see why that should be hard.
but this already needs some hacks directly in the renderer to work. Imagine what this might produce if it has to be done per sector.
When I made this test wad, I thought, based on the Boom reference, that it really divided the sector by height into two or three independent sectors. Apparently that's not within the renderer's capability.
User avatar
Kate
... in rememberance ...
Posts: 2975
Joined: Tue Jul 15, 2003 8:06 pm

Re: Problem with Transfer_Heights

Post by Kate »

koverhbarc wrote:First, why does this board change my username to 'Betsy Senningtock'?
Names are randomly generated if you don't log in to post. I'm surprised you weren't alerted that you weren't logged in by the fact that it asked you to solve a captcha to post.
Post Reply

Return to “Closed Bugs [GZDoom]”