?Help?linked_portal_door performs ugly ~_~
Quote from Doomaflatchi on August 12, 2014, 6:52 pmActually, the engine can support 131 open linked_portal_doors at once before it crashes. Seriously. 0_0
The recursion problem mentioned by several previous posters has to do with portals which are overlapping within their associated visleafs. Because of how the game renders portals within a space, the portals do not actually create any sort of visleaf divide, and so the room behind them continues to draw normally - but the engine is also trying to draw the space within the portals, as well. When the game starts trying to draw portals behind portals, or where too many spaces are trying to overlap in the drawcalls, then it starts throwing those red recursion errors.
I've found that putting bounding geometry (like a tools/skybox brush, for instance) behind linked_portal_doors makes them behave much more predictably. Think of it like leaking maps, but with space instead of light - use geometry to keep that space from leaking through multiple portals when drawn from any one point. I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction. With the exception of visual lag (solved by putting in a sensible Far Z Clip plane to the map), it works perfectly, and with NO recursion errors. The trick is bounding each cube and its associated portals with another skybox cube just past them. Sticking to less than four portals at once will prevent the problem, but it's not the cause of the problem.
Actually, the engine can support 131 open linked_portal_doors at once before it crashes. Seriously. 0_0
The recursion problem mentioned by several previous posters has to do with portals which are overlapping within their associated visleafs. Because of how the game renders portals within a space, the portals do not actually create any sort of visleaf divide, and so the room behind them continues to draw normally - but the engine is also trying to draw the space within the portals, as well. When the game starts trying to draw portals behind portals, or where too many spaces are trying to overlap in the drawcalls, then it starts throwing those red recursion errors.
I've found that putting bounding geometry (like a tools/skybox brush, for instance) behind linked_portal_doors makes them behave much more predictably. Think of it like leaking maps, but with space instead of light - use geometry to keep that space from leaking through multiple portals when drawn from any one point. I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction. With the exception of visual lag (solved by putting in a sensible Far Z Clip plane to the map), it works perfectly, and with NO recursion errors. The trick is bounding each cube and its associated portals with another skybox cube just past them. Sticking to less than four portals at once will prevent the problem, but it's not the cause of the problem.
Quote from Freeman|TR on August 13, 2014, 10:20 pmDoomaflatchi wrote:Actually, the engine can support 131 open linked_portal_doors at once before it crashes. Seriously. 0_0The recursion problem mentioned by several previous posters has to do with portals which are overlapping within their associated visleafs. Because of how the game renders portals within a space, the portals do not actually create any sort of visleaf divide, and so the room behind them continues to draw normally - but the engine is also trying to draw the space within the portals, as well. When the game starts trying to draw portals behind portals, or where too many spaces are trying to overlap in the drawcalls, then it starts throwing those red recursion errors.
I've found that putting bounding geometry (like a tools/skybox brush, for instance) behind linked_portal_doors makes them behave much more predictably. Think of it like leaking maps, but with space instead of light - use geometry to keep that space from leaking through multiple portals when drawn from any one point. I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction. With the exception of visual lag (solved by putting in a sensible Far Z Clip plane to the map), it works perfectly, and with NO recursion errors. The trick is bounding each cube and its associated portals with another skybox cube just past them. Sticking to less than four portals at once will prevent the problem, but it's not the cause of the problem.
Much thanks to the explanation!The cause seems to be deep inside the engine.I think I could find out the solution gradually as I learn more about hammer ^^
The recursion problem mentioned by several previous posters has to do with portals which are overlapping within their associated visleafs. Because of how the game renders portals within a space, the portals do not actually create any sort of visleaf divide, and so the room behind them continues to draw normally - but the engine is also trying to draw the space within the portals, as well. When the game starts trying to draw portals behind portals, or where too many spaces are trying to overlap in the drawcalls, then it starts throwing those red recursion errors.
I've found that putting bounding geometry (like a tools/skybox brush, for instance) behind linked_portal_doors makes them behave much more predictably. Think of it like leaking maps, but with space instead of light - use geometry to keep that space from leaking through multiple portals when drawn from any one point. I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction. With the exception of visual lag (solved by putting in a sensible Far Z Clip plane to the map), it works perfectly, and with NO recursion errors. The trick is bounding each cube and its associated portals with another skybox cube just past them. Sticking to less than four portals at once will prevent the problem, but it's not the cause of the problem.
Much thanks to the explanation!The cause seems to be deep inside the engine.I think I could find out the solution gradually as I learn more about hammer ^^
Quote from protoborg on August 14, 2014, 2:47 pmDoomaflatchi wrote:I am currently working in a map which takes 8 cube-shaped rooms and organizes them into a tesseract by connecting their sides together, using 48 linked_portal_doors to connect them at the side faces, creating a space which loops infinitely in every direction.That sounds like it would be fun to explore for a while. I once tried to make a tesseract. I gave up after a while due to the extreme difficulty I encountered. I hope you release the level as I would love to explore THAT test chamber.
That sounds like it would be fun to explore for a while. I once tried to make a tesseract. I gave up after a while due to the extreme difficulty I encountered. I hope you release the level as I would love to explore THAT test chamber.