Haplo on 11/10/2018 at 11:50
A while ago I posted that my complicated railing was causing the infamous error below during optimisation:
Code:
ERROR: remove_poly_edge: edge not in poly list.
ERROR: portalization failed, no WR was generated (try to locate and tweak problematic location or brush)
This seemed to be due to small intersecting cylinders in the railing. I worked around it by simplifying the brushes. I was able to continue building after that.
Well, until now, that is. Now I'm trying to add one final room and I'm getting this error again. So I went back a couple of saves and tried playing around with the existing architecture:
- I noticed that the number of cube brushes I was able to add was limited to a handful more. If I removed a cube brush from anywhere else, it allowed me to add exactly one more in my new room.
- In the parts that I had two or more cylinders with the base of 10 connecting or intersecting, if I removed one of the cylinders, it allowed me to add 4 to 5 cube brushes more. Until now it kind of made sense in its own way, I guess.
- Now this is the interesting part: I have a few pyramids with base of 10 and height of 1 or 2 that I have scattered around the mission, to create "bumps" in the otherwise smooth ground, for realism. I noticed that if I removed any of these, it would actually
reduce the number of brushes I could add. If I removed a couple of them from a perfectly working mission, it would actually fail to optimise with the error above.
- So I went forward to the final save which had the new room and was failing as I explained above, and added a couple of those bumps somewhere else in it, and it actually optimised. Even when I add intersecting cylinders in this new room, I can still make it optimise just by adding enough of those pyramids around the mission.
All these brushes are aligned to a grid size of 11 or bigger, by the way.
Until now I thought this error was due to intersecting cylinders or high concentration of cells in small areas. But if this is the case why adding random 10-side pyramids around the mission makes it go away?
Anybody has experience with this? Thanks.
Cardia on 11/10/2018 at 12:15
I´ve experienced that several times, i remember once it was due to solid edges brushes being intersected with solid square brushes, somehow i´ve managed to solve the problem, try to remember the last shapes you added before that error, eventually you´ll have to do it, remove the brushes you think are problematic until the error goes away.
Unna Oertdottir on 11/10/2018 at 13:48
My trial and error solution is to create a blockable brush close to the point where the error occurs (or even inside the bad spot). This often works, also with pathfinding errors. I've no explanation, but obviously the geometry has changed. If this doesn't work, a small air brush around the spot (time=1) should help.
pukey brunster on 11/10/2018 at 15:22
Hey Haplo, my reply to this may not be relevant at the time, back to your issues with railings. Have you considered making the railings out of objects instead of brushes? I know this doesn't answer your current question, but thought I'd put it out there.
Tannar on 11/10/2018 at 15:33
Regarding pukey's suggestion, we've made railings using secret doors which have replaceable textures. The downside is that objects are either lit or unlit so you may not be able to do this everywhere, but we've had some good success with this and it certainly reduced cell count.
Haplo on 11/10/2018 at 22:53
Thanks for the replies.
Unfortunately for me the problem manifests itself in a different way. DromEd doesn't show the error because of something I have just built. Looks like when I build something that Lord DromEd doesn't like, it simply assigns me a quota of a couple of hundred for any new brushes. When I reach that quota, it throws a fit.
For example I had built those railing back in May, but DromEd started complaining in August. I suspected the railing only because I noticed the patrol routes around it were broken and which pointed to high cell count. That railing is super simple now so I don't think it is an issue any more.
In this new case I had added a few connecting cube brushes (a hallway and a room). As simple as you can be, really. I'm just paying for something that I have done probably a month or two ago.
What I find interesting is adding unrelated pyramids in other locations makes this go away. To me it seems like a bug in the code, which happens in certain conditions when DromEd is traversing its array/linked list/tree of brush edges looking for intersections. When those unrelated brushes are added the order of data changes and things get shifted up or down, removing the conditions that trigger the bug.
Time to dig in the code, I guess.
R Soul on 11/10/2018 at 23:12
Have you tried changing the Time numbers for the suspicious brushes? When the world is built Dromed starts with the first terrain brush, then the second etc. E.g. if you have two rooms with complicated shapes, try having all the brushes of room 1 earlier in time than those for room 2. Or try having any air brushes that link the two rooms (halls, doorway etc) moved to a later time value.
pukey brunster on 11/10/2018 at 23:36
Or, just go back and delete the "simple" brushes you used as railings. I don't think cylinders are really necessary as railings, are they? Sometimes, just go back and get rid of the unnecessary. Use objects as railings. Then, maybe, the things that really matter where you are building won't break your mission in the same visible area.
Haplo on 12/10/2018 at 05:52
Thanks. As I mentioned above, the railing doesn't have any cylinders any more, and since I'm getting this error with a "delay", it's not easy to figure out which part of the mission DromEd is not happy with.
I took a look inside the CSMERGE code. The remove_poly_edge() function takes two parameters: a portal polygon and a portal poly edge. It iterates through all the polygons that share the edge of that portal polygon to see if any of them is the same as the given portal poly edge. If it doesn't find any after going through 2048 of them, it throws the "remove_poly_edge: edge not in poly list" error.
This kind of explain my two observations, at least to some extent. I have a "quota" of how many more brushes I can add. After that point, it looks like that particular edge is shifted past the 2048th position. And somehow, adding random pyramids brings it back to a position smaller than 2048. I need to dig deeper in the code to see how these linked lists are constructed.
However...This magic number of 2048 doesn't seem to have been used anywhere as the size of any of the relevant arrays, or as the maximum number of elements in the link list. There is no NULL check as the pointer is advanced in the loop, and there are no segfaults, so it means there are indeed 2048 or more polygons in the list of that portal edge. That 2048, although quite high, seems to be an arbitrary number. I wonder if increasing it and adding a NULL check will improve this code and let is function for higher complexity architectures.