Polyobjects

Another polyobject question - what's the maximum number you can have in any one map? (as I've read somewhere that too many can cause problems)

I'm not sure, but you should be able to have at least 256 of them if not more

And am I right in thinking that you're not supposed to put any linedefs, sectors or non-solid things in their path?

Yes.

Beware: Polyobj init gets very slow when you have lots of them in an big map. Even with just 20 in a relatively large map setup can take a few seconds so if you have even more you can do the math...

Ultimate DooMer said:

And am I right in thinking that you're not supposed to put any linedefs, sectors or non-solid things in their path?

yep, if a polyobj leaves the sector it's placed in (ie the source sector, not the dummy sector you make it in) then you get major bleeding and stuff

I don't recall what happens if you put a line in front of it that's refed to the sector, as I never tried it, but I assume the same result, but you could always try it out

I'm not sure exactly how many can be in a map, but I have found out that there can't be more than 32 linedefs per polyobject.

Ichor said:

I'm not sure exactly how many can be in a map, but I have found out that there can't be more than 32 linedefs per polyobject.

That's not quite correct. The limit is 64 segs so it also depends o how the linedefs are split by the node builder, but only if you use Polyobj_ExplicitLine. If you use Polyobj_Startline there should be no limit (at least I cannot find any in the source.)

There is one other thing. Never place the origin of a polyobject at a place so that it might be in the line of sight between the player and the destination of the polyobject, even if obstructed by obe sided walls. KZDoom7 has one of those and it creates really weird effects so that some walls occasionally disappear. Only after I moved it further away it worked correctly.

Graf Zahl said:

There is one other thing. Never place the origin of a polyobject at a place so that it might be in the line of sight between the player and the destination of the polyobject, even if obstructed by obe sided walls.

Not really sure what you are trying to say - that's not a very clear description. One never "sees" the model. The way I read it (in the context of one sided walls), I'd say that is actually not true. You can put the model anywhere you like, however, remember that ALL lines in a level get processed by the BSP.

Polyobjects are sensitive to rendering/bsp errors. Most people are unaware that the surrounding areas (even a bit a away from the area) directly affects the BSP, so when things fruck up with polyobjects, they often come to erroneous conclusions. So it has nothing to do with "line of sight" and everything to do with the surrounding area. Angles lines make the problem worse. What you did is a common way to fix it.

The orginal HEXEN levels contain good examples of what was done to "fix" polyobject rendering errors. Weird stuff if you look at it in the context of "what the hell does that line do?".

deep said:

Not really sure what you are trying to say - that's not a very clear description. One never "sees" the model. The way I read it (in the context of one sided walls), I'd say that is actually not true. You can put the model anywhere you like, however, remember that ALL lines in a level get processed by the BSP.

Polyobjects are sensitive to rendering/bsp errors. Most people are unaware that the surrounding areas (even a bit a away from the area) directly affects the BSP, so when things fruck up with polyobjects, they often come to erroneous conclusions. So it has nothing to do with "line of sight" and everything to do with the surrounding area. Angles lines make the problem worse. What you did is a common way to fix it.

The orginal HEXEN levels contain good examples of what was done to "fix" polyobject rendering errors. Weird stuff if you look at it in the context of "what the hell does that line do?".

I agree that it is most likely a BSP problem.
No matter what is the cause the lesson should be to put the polyobj origin as far away from the spawn point as possible. All the really ugly problem seem to appear only when the polyobj origin is relatively near to its spawned position.

I'd better move the void sector away from the doors, then... (I've not had any trouble yet, but I probably will at some point)

BTW, can Zennode cause trouble with them? (as I read that it's not perfect in handling polyobjects)

Graf Zahl said:

I agree that it is most likely a BSP problem.
No matter what is the cause the lesson should be to put the polyobj origin as far away from the spawn point as possible. All the really ugly problem seem to appear only when the polyobj origin is relatively near to its spawned position.

Just look at XTHEATERIII to disprove that hypothesis. In fact, I deliberately put my polyobjects as CLOSE to the spawn point as possible to make editing easier. The model is no different than any other object in the level - it's all about the target area geometry.

Here's a simple suggestion: minimize the angled lines close to/around the target polyobject. For example, rectangled areas almost never screw up.

Graf Zahl said:

I agree that it is most likely a BSP problem.
No matter what is the cause the lesson should be to put the polyobj origin as far away from the spawn point as possible. All the really ugly problem seem to appear only when the polyobj origin is relatively near to its spawned position.

I have always put my polyobjs right near the spawn point. that's not an issue that causes bleeding. one of the major things that causes bleeding is if the polyobj slides behind a 1s linedef which can be fixed by making that a 2s linedef (with a sector behind it of course). I'll make an example and post it in a sec.

Edit: alrighty, http://cyb.vect.org:8080/misc/pbleed.zip

built the nodes with warm, actually if you let zdoom build the nodes the second one doesn't even bleed, also lwm's advice below is also excellent, I had totally forgotten about that

If I may come out from under my rock for a moment, Randy taught me to put the polyobject's destination in it's own subsector. That alone seems to have fixed any display problems I ever had, and allowed for more creative freedom in their placement.

Also, Gunsmith Cats is my most prolific use of them, at 57. I've never noticed any extra delay in build/load times vs. poly-free levels of similiar size.

Back under my rock now.

LilWhiteMouse said:

Also, Gunsmith Cats is my most prolific use of them, at 57. I've never noticed any extra delay in build/load times vs. poly-free levels of similiar size.

Back under my rock now.

How are you defining them? On my system the startup time of KZDoom7 (great level, btw) is >5 seconds and that is only due to the 20 polyobjects in there (I debugged the code to find that out) This is a fairly large level (>6000 linedefs) and many of the polyobjects are quite large. The thing is that the polyobject init code for Polyobj_Startline is highly inefficient (it was that in Hexen and nobody has changed it until now) and steps through the entire list of segs for each seg it needs. So if the polyobject segs are rather late in the list it would significantly increase the startup time.

Polyobj_Explicitline doesn't seem to have this problem but I never have used it because it's too tedious.

Graf Zahl said:

How are you defining them? On my system the startup time of KZDoom7 (great level, btw) is >5 seconds and that is only due to the 20 polyobjects in there (I debugged the code to find that out) This is a fairly large level (>6000 linedefs) and many of the polyobjects are quite large.

Polyobj_Startline for most of them, a few Polyobj_Explicitline, and none of them use the crushing start spot. All of my polyobjects are only four or two sided, perhaps that's it? GSC has a hair over 5000 linedefs, for reference.

LilWhiteMouse said:

Polyobj_Startline for most of them, a few Polyobj_Explicitline, and none of them use the crushing start spot. All of my polyobjects are only four or two sided, perhaps that's it? GSC has a hair over 5000 linedefs, for reference.

I think its something like (number of all segs) * (number of all polyobj segs) which is the deciding factor so it might vary even in large maps. This does not take into account where the segs are placed in the array. If they are at the beginning it will obviously be faster. Since all this depends mainly on the nodes builder this cannot be easily controlled and I have no idea how the segs are ordered in the WAD. Maybe it was just a case of bad luck for KZDoom7.

LilWhiteMouse said:
If I may come out from under my rock for a moment, Randy taught me to put the polyobject's destination in it's own subsector.

That's a given rule. You can never have a polyobject cross subsectors. There are other issues which Cyb's level demonstrates - basically split up the sector into segments that surround the polyobject. I'd line up all the anchors with the targets though (like the rightmost one), since that makes a more efficient tree (or just align them with any other linedef if possible - the 1st one is like that).

I've never noticed any extra delay in build/load times vs. poly-free levels of similiar size.

Neither have I. Most of the extra time is usually texture allocation/expansion and just going through the level doing some basic checks. Even a million checks is actually done in a heartbeat - we do have 1000+-MIP desktops now! KZDOOM7 loads in 2 seconds - average for this size level.

Back under my rock now.

OK:)