Cross-portal sector bleeding.

[Super Chex]

Hello.

I've been experimenting with using line portals and polyobjects to create movable geometry for vehicles and such. There is an issue with the technique. Upon standing on the inside of the vehicle boundary, sector bleeding does not function.

Standing outside, sector bleed works fine:


Inside, bleeding doesn't work, causing black artifacting:


Was wondering if this is possible to fix, and if it is, whether or not such a feature could be added.

Sorry if this is more of a bug than a feature request. I can't tell which this counts as, since it seems to be expected behavior.

[Graf Zahl]

I cannot even fathom what you did here. One thing is sure: You abused some techniques that aren't even supposed to work. At the very least post the map to get an evaluation.

[Super Chex]

I cannot even fathom what you did here. One thing is sure: You abused some techniques that aren't even supposed to work. At the very least post the map to get an evaluation.

Apologies. Attached is the wad that contains this setup. Use "pukename RCStart" to control the vehicle, and the USE key to exit.

[RockstarRaccoon]

I cannot even fathom what you did here.

I'm pretty sure he tried to use a rectangular-shaped portal-polyobject to wrap a non-rectangular piece of geometry.

Super Chex> This is the engine working as intended: portals are SUPPOSED to snip floors like that. The bleed thing only works because the engine doesn't bother to cut up the floor for the polyobject (which would be stupid), and is not a behavior you should rely on. I suggest you redo the polyobject with the outline of the geometry matching the polyobject enough that they don't flip their shit like this, OR try to use some sort of MD3 based system, as using portals to do something like this is going to be messy and you can do it much cleaner nowadays with .MD3s.

[Super Chex]

I cannot even fathom what you did here.

I'm pretty sure he tried to use a rectangular-shaped portal-polyobject to wrap a non-rectangular piece of geometry.

Super Chex> This is the engine working as intended: portals are SUPPOSED to snip floors like that. The bleed thing only works because the engine doesn't bother to cut up the floor for the polyobject (which would be stupid), and is not a behavior you should rely on. I suggest you redo the polyobject with the outline of the geometry matching the polyobject enough that they don't flip their shit like this, OR try to use some sort of MD3 based system, as using portals to do something like this is going to be messy and you can do it much cleaner nowadays with .MD3s.

That was how I had originally done it, the problem is that if I do that, the number of portal recursions exceeds GZDoom's default value of 4, thanks to the complexity of the car's geometry. This means that in order for people to use it properly, they'd need to turn up the recursion limit to 5 or higher in order to not see a "slime trail" type of effect, depending on the complexity of the geometry in question.

This is actually why I switched to a simple box. It just seems like bad form to force people to change a fairly obscure setting just to avoid artifacting. To make matters worse, in OpenGL, the portal recursion isn't controlled by the portal recursion limit CVAR, but the mirror reflection recursion CVAR. This makes it even more annoying for the end-user.

EDIT: Clarification.

[Caligari87]

If the CVar isn't working properly, that should probably be a bug report. That aside, portals have that limit because they can overload the user's computer very quickly. 10 portals might be playable for you but 3 portals for someone else might be nigh-unusable.

Besides, this seems like a HORRIBLY inappropriate abuse of polyobject portals for zero net gain except "it's technically possible". Seconding the suggestion that you should be using models for this kind of thing.

[RockstarRaccoon]

Yeah, portals are an EXTREMELY messy feature of ZDoom: they have to render literally EVERYTHING in view of that line in order to draw the small section you can see. It's a complete mess when you use them for shit like this where it's actually going to move around a big open area, because ALL of those details need to be processed and rendered constantly.

The only version of the engine which can reasonably do what you're trying to do here is the Sonic 3D Blast engine, and support for that functionality has never been attempted in the main build.

Meanwhile, an MD3 takes a fraction of the rendering power of a polyobject and is easier to get better detail out of. You should grab Misfit or Wings or Blender or something and just go with that.

[Cacodemon345]

Sonic 3D Blast engine is very different, despite being based on the Doom Engine.

[Graf Zahl]

Portals are a very unnatural thing in the Doom engine. This means they cannot be rendered 'naturally' as part of the regular geometry. They are very expensive to set up, very expensive to render and still do not integrate this greatly. They are fine for creating a passage between two sections of a map or overlaying a detailed ceiling over another area but for such small scale stuff they are entirely unfitting.

With today's hardware you get a lot of mileage but it's still important that the overall shape of a portal area remains simple. This "polyportal" stuff is anything but.

[Cacodemon345]

And with the inherent limitations of the sectors being unable to move horizontally, we are forced to resort to such kind of fakery. Sonic 3D Blast is better for that, as it support horizontally-movable polyobjects, but I seriously doubt it will be available in the Doom engine.

[Nash]

I'd use models for these kinds of things. Software rendering will be getting model support too in future!

(and for those who don't like to use models, you can use voxels)

[Graf Zahl]

It was added to this engine, it can surely be added to GZDoom - provided you find someone willing to sink weeks or months of work into such a feature.

But the main question is: Why do you work with a Doom-based engine if you NEED features the engine does not support? You either have to scale down a bit or face problems. And the more you hack around the more likely your map may break later.

[Cacodemon345]

A far better solution would be actors having the ability to move other actors above. Combine that with voxels, and it is better.

[RockstarRaccoon]

That is already a thing that people have gotten to work.

[Super Chex]

Thanks for the explanations, folks. It really was meant as more of a tech demo than an actual practical case thing. I was half-hoping that it could take off and be a fairly common niche mapping trick, but if it's that unoptimized, then it's probably best that it isn't used that often, if at all.