Cross-portal sector bleeding.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Cross-portal sector bleeding.

Re: Cross-portal sector bleeding.

by RockstarRaccoon » Fri May 11, 2018 2:52 pm

Super Chex wrote: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.
It's a thing I've seen people do, and it apparently works if you don't stand on top of it and look at the sides, but with software support for models coming up, and zscript, I just don't see the point of this...

Re: Cross-portal sector bleeding.

by Super Chex » Fri May 11, 2018 1:05 pm

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.

Re: Cross-portal sector bleeding.

by RockstarRaccoon » Thu May 10, 2018 8:39 am

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

Re: Cross-portal sector bleeding.

by Cacodemon345 » Thu May 10, 2018 1:57 am

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

Re: Cross-portal sector bleeding.

by Graf Zahl » Thu May 10, 2018 1:54 am

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.

Re: Cross-portal sector bleeding.

by Nash » Thu May 10, 2018 1:53 am

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)

Re: Cross-portal sector bleeding.

by Cacodemon345 » Thu May 10, 2018 1:46 am

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.

Re: Cross-portal sector bleeding.

by Graf Zahl » Thu May 10, 2018 1:43 am

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.

Re: Cross-portal sector bleeding.

by Cacodemon345 » Thu May 10, 2018 1:15 am

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

Re: Cross-portal sector bleeding.

by RockstarRaccoon » Wed May 09, 2018 6:34 pm

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.

Re: Cross-portal sector bleeding.

by Caligari87 » Tue May 08, 2018 6:05 pm

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.

8-)

Re: Cross-portal sector bleeding.

by Super Chex » Tue May 08, 2018 5:37 pm

RockstarRaccoon wrote:
Graf Zahl wrote: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.

Re: Cross-portal sector bleeding.

by RockstarRaccoon » Mon May 07, 2018 10:18 pm

Graf Zahl wrote: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.

Re: Cross-portal sector bleeding.

by Super Chex » Tue May 01, 2018 3:25 pm

Graf Zahl wrote: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.
Attachments
rcpoly.wad
(16.72 KiB) Downloaded 79 times

Re: Cross-portal sector bleeding.

by Graf Zahl » Tue May 01, 2018 2:58 pm

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.

Top