Hiyas,
> It's been a long while since I did my first portal demo in blitz( a shameless linepick system ). I keep meaning to try my new method but find myself not having time to dedicate in this area of programming( ie: I'm into modelling creation mode lately. Lots ta learn and do! Need the media bad... no cash to buy media, dont really want media that other people use anyway... so gotta do it me self. ).
> I'm meaning for this thread to be a discussion on ideas of implementing various portal systems (old & new) to hopefully help others to implement or even mabie derive new ideas from, but as for me I feel that I will only be using this one method that I'm about to describe in any future projects that I may need it. So, I MAY not be able to have any good constructive feedback with any other method as I am so focused on this one. I really wanted to build up a free demo with source code with this, anxious to show how simple this is to all, but again just can't find the time to dedicate for it quite yet. Yes Masterbeaker's "PortalPal" inspired me to write this thread! :) And plus, that other thread about portals from rob, "the portal challenge"? is a bit big.
SECLUDED PORTALS( or "K.I.S.S. Portals" if you likes :P ) :
1) No polygon clipping
2) No portal recursion( ie: no seeing if other portals can been seen through any other visible portals "in camera view" )
3) No potential visibility sets
4) No BSP pre-compilation to magically create crazy amounts of portals. ( oh portal placement optimization should help that out there = more time to process. )
> With just those 4 features above, imagine how much processing time you will save alone without them... even on developement time. As we know, portals are generally defined as 2d shapes ( ie: doorways, windows, etc.) in a 3d world. Common portals that are used in commercial games ( ie: usually in a BSP/Portal system hybrid ) will at least do polygon clipping against portals and portal recursion. Either a BSP compiler will compute portals automagically or level engineers can somehow manually place them into the scene to seperate sections of the level.
> So whats so simple about secluded portals? Ideally, you want to manually place them, but the difference here is that you want to place them where they CAN NOT see another portal (ie: "secluded" ). A whole lot less code then long winded code to do portal recursion and other stuff. Here, you just checking to see if any of the current room's portals can be seen or not, if so then render adjacent room. That is pretty much it! No need to see if you can see any other portals beyond your current section's portals. Ofcoarse, you will need a way to know when you pass through a portal to a new section [explained below]. The idea here is to keep the portal method as simple as can be and this is the most basic portal system that I can think of at the moment. K.I.S.S.!!!
Implementation:
> We need an level editor of some sort where we can create SECTIONS of the level for the entire game level that we want. With the idea of the rule that the portals shall NOT see each other in the back of our minds, we need to model the sections in such a way to cater for this basic rule. For indoor levels as for an example, imagine a hallway connecting to two rooms. Normally, we would put two portal at each end of the hallway at the doorways that connects the hallway to the rooms. With secluded portals thats a no no. Imagine those two rooms with another doorway off to the left that leads off to yet another section of a level as you come out of the hallway into either room. With the doorways that connect the hallway and rooms, if you create the rooms big enough and create the hallway long and thin, the polygons that make up all of the rooms and hallway should make the other doorway in each room that are NOT connected to the hallway unable to see each other. Perfect places for secluded portals.
> You have to think a bit more creative here than with regular portals systems as for designing levels, but I believe strongly it's very worth while to do. You have complete control on how many polygons each section that you model has. With that and with no realtime portal recursion and no polygon clipping, I can see this as the fastest portal method at least for blitz in my mind. Also, this should work nicely with the .b3d format.
> These doorways will define the portal's shape. So basically each section of the level where you have an opening that will connect to the opening of an adjacent section will have a portal there. To me, I think this would be the hardest part of the process but yet easy enough to do if we had the tool to do that( I'm trying to write one myself :\ ). We need the level editor, or the custom editor where you would manually place the sections of the level togethor to create the whole level, to be able to let us grab the vertex points that make up the openings(ie: doorways, window, etc...) where portals need to go. We need to save those vertices in a clockwise order so we can reconstruct the portals as an alpha 0'd mesh ( or simulate them as a mesh if you have your own linepick method ) in our game to test if player passed through them or not. The data needs to save each portal info along to what section the portals belong to. The portals need also info on what adjacent section of the level that you would be able to see through it.
> At run time, we want the current section that the player is in and any ADJACENT section to have collision on ( ie: we use EntityAlpha 0 or 1 to keep collision on for the sections we want). Any sections that are not adjacent to the current section we use HideEntity command on them. So when a section becomes adjacent to the current section that the player is in, do a one time ShowEntity on it and then use EntityAlpha 0 or 1 when a current room's portal is in view or not. Here we need a little system to remmeber what sections are currently adjacent because once you move through a portal into another section we automatically get NEW adjacent sections. After you move into a new section, you need do a one time HideEntity on the sections that are no longer adjacent to you ( ie: obviously the section that you moved into to WAS an adjacent room, just make your code overide the HideEntity on that section because it's now the current room ).
> We need to know when we move from one section to another. You can either use a the LinePick command to use the old player location to point to the new player location and see if the LinePick passed through a "Pickable" portal. Here you would have a 2d shaped mesh in the 3d world for the portal and had applied EntityAlpha 0 to it. Or you can use you own custom linepick if you like. Just need some kind of way to see if you passed through the current room's portal. Once that check is made and the return value holds true that you indeed have passed through the portal then you can switch current sections appropriately.
Some notes:
[blitz built in camera view occlusion]
> I can almost hear someone say, "let blitz occlude adjacent sections by itself instead of alphaentity 0'ing them.". The thing to remmeber here is the level design. The doorway where the portal is may be out of camera view, but depending on how big the adjacent section is and it's shape, it could very well still be in camera's view. So when the current section's portal is out of view, do alphaentity 0 on it! (ie: less polys in view and less overdraw ).
[Amount of Portals for each section]
> As with normal portal systems, the more portals you use for the current section, the slower it gets. Here, we are just worrying about how many polys each section has (ie: the current section and any portals that are in camera view in which would show adjacant sections) and mabie how much overdraw there is since we are not doing any polygon clipping against the portals themself. As we place portals so it can not be seen by any other portal, the adjacent rooms may be big by design so I would keep the max of portals a section can have low like 3 or 4. Ofcoarse 1 portal is the best scenerio and I would imagine 2 portals for a section would/should be the average.
[outdoors!]
> Ya betch ya! If you have a bunch of hills, canyons, giant boulders, mabie with fog, and are unable to go above a certain height, you can make some wild terrain. Just make the outdoor terrain section big enough and wild enough so you can place portals without seeing each other. Almost like creating indoor sections except with no visible ceiling. I'm still thinking of that outside terrain like the unreal torny 2003 demo had. Or make you a jungle with perty trees!
> For flatter terrains, them rolling hills, I would use what I call a terrain pound system (ie: pound = # ). You would just simply have the 8 adjacent terrain section using alphaentity 0 or 1 depending what adjacent sections are in view or not. Since the terrain sections are square along the x and z axis, I hope it would be easy for you to determine if you walk off the current terrain section to another. ;) Ofcoarse, I'm thinking of good sized terrain sections here with the wonderful fog that we all know and love X) so we can't see pass the adjacent terrains.
[Integrating Indoor and outdoor]
> That's another thing that I'm "planning" to implement into my editor is a outdoor sectioned terrain system where I can cut holes in the terrain, move the outside model of the building approximally in the cut out hole area of the terrain and then move the terrain vertex points to basically connect or snap on to vertices of the outside model of the building or even be able to add polys to fill in gaps. Seamlessly, I can place the indoor section under this outside model of the buidling where you would have the a "doorway" where you can go in and out of the building at... [breath]... and save data for the indoor section's portal to know that it will connect/see/"Be adjacent" to terrain section. The terrain section will actaully have a portal leading into the building at that doorway. IT will know what adjacent section it will show/hide. More clearly here, the outside building is part of the terrain section and the portal that leads into the building is also part of the terrain section. ta da!
[NPC's & Multiplayer Players]
> Obviously our npc's and other multiplayer players would want to have collision when moving around specially when they are not in the main player's current section and any of current section's adjacent sections. Each npc and/or multiplayer player will act like the main player, it will have a current section that it is in. There will just be no need of alphaentity 1 on it's current section when we can not see them. If the npc's or multiplayers are in the main players current section or in a section that is adjacent to the main player's current section which is in camera's view view portal being in view, then there is no need to to on or off the collision for them. [note: you can work any other 3d objects that need to be move around in this way also. ahhhhh... physics]
[Forgot to add above: HideEntity on Adjacent Sections that are not in view]
> Well, without seeing how all this works code wise and in action, this could be a little problem to overcome for me. I remmeber in a portal system I was working on for the first project plasma community project when the player would back up into an adjacent section that was not in camera view and had alphaentity 0 on it to have collision on, sometimes I would catch the black empty space of nothingness at a corner of the camera view until I actually pass the portal or something like that. My portal should have been in camera view where it would have shown the adjacent section without the alphaentity 0 still be on for it. But, I probably did something wrong there. This idea should work though where when you pass the portal, do a showentity and entityalpha 1 on the new section so to be able to see it and not fall through the floor via gravity.
CONCLUSION( finally ):
> Little bit long, but hopefully someone out there can understand my jibberish here and can see that this should be a nice little system to use if so desired. It should be fast! I really do hope someone can make use of this method. I really do believe in it. It just taking me forever to get to it so I thought I would just share the info about this method. I have search high and low for any description of a simple basic method like this on the internet but just can't find anything similar. Probably just missed it and ofcoarse I'm sure somebody else would claim they done it before. big deal. If someone else implements it before I can, I really would love to see it!
> Whenever, I get my little editor to manualy place sections togethor, make terrain sections, gather portal information and make a demo along with source code for this method, I'll definetly release it for free for PD. Just need to find the time to do it! ...And I really want to do it! :\
* Feel free to discuss about this method and any other method here.
> It's been a long while since I did my first portal demo in blitz( a shameless linepick system ). I keep meaning to try my new method but find myself not having time to dedicate in this area of programming( ie: I'm into modelling creation mode lately. Lots ta learn and do! Need the media bad... no cash to buy media, dont really want media that other people use anyway... so gotta do it me self. ).
> I'm meaning for this thread to be a discussion on ideas of implementing various portal systems (old & new) to hopefully help others to implement or even mabie derive new ideas from, but as for me I feel that I will only be using this one method that I'm about to describe in any future projects that I may need it. So, I MAY not be able to have any good constructive feedback with any other method as I am so focused on this one. I really wanted to build up a free demo with source code with this, anxious to show how simple this is to all, but again just can't find the time to dedicate for it quite yet. Yes Masterbeaker's "PortalPal" inspired me to write this thread! :) And plus, that other thread about portals from rob, "the portal challenge"? is a bit big.
SECLUDED PORTALS( or "K.I.S.S. Portals" if you likes :P ) :
1) No polygon clipping
2) No portal recursion( ie: no seeing if other portals can been seen through any other visible portals "in camera view" )
3) No potential visibility sets
4) No BSP pre-compilation to magically create crazy amounts of portals. ( oh portal placement optimization should help that out there = more time to process. )
> With just those 4 features above, imagine how much processing time you will save alone without them... even on developement time. As we know, portals are generally defined as 2d shapes ( ie: doorways, windows, etc.) in a 3d world. Common portals that are used in commercial games ( ie: usually in a BSP/Portal system hybrid ) will at least do polygon clipping against portals and portal recursion. Either a BSP compiler will compute portals automagically or level engineers can somehow manually place them into the scene to seperate sections of the level.
> So whats so simple about secluded portals? Ideally, you want to manually place them, but the difference here is that you want to place them where they CAN NOT see another portal (ie: "secluded" ). A whole lot less code then long winded code to do portal recursion and other stuff. Here, you just checking to see if any of the current room's portals can be seen or not, if so then render adjacent room. That is pretty much it! No need to see if you can see any other portals beyond your current section's portals. Ofcoarse, you will need a way to know when you pass through a portal to a new section [explained below]. The idea here is to keep the portal method as simple as can be and this is the most basic portal system that I can think of at the moment. K.I.S.S.!!!
Implementation:
> We need an level editor of some sort where we can create SECTIONS of the level for the entire game level that we want. With the idea of the rule that the portals shall NOT see each other in the back of our minds, we need to model the sections in such a way to cater for this basic rule. For indoor levels as for an example, imagine a hallway connecting to two rooms. Normally, we would put two portal at each end of the hallway at the doorways that connects the hallway to the rooms. With secluded portals thats a no no. Imagine those two rooms with another doorway off to the left that leads off to yet another section of a level as you come out of the hallway into either room. With the doorways that connect the hallway and rooms, if you create the rooms big enough and create the hallway long and thin, the polygons that make up all of the rooms and hallway should make the other doorway in each room that are NOT connected to the hallway unable to see each other. Perfect places for secluded portals.
> You have to think a bit more creative here than with regular portals systems as for designing levels, but I believe strongly it's very worth while to do. You have complete control on how many polygons each section that you model has. With that and with no realtime portal recursion and no polygon clipping, I can see this as the fastest portal method at least for blitz in my mind. Also, this should work nicely with the .b3d format.
> These doorways will define the portal's shape. So basically each section of the level where you have an opening that will connect to the opening of an adjacent section will have a portal there. To me, I think this would be the hardest part of the process but yet easy enough to do if we had the tool to do that( I'm trying to write one myself :\ ). We need the level editor, or the custom editor where you would manually place the sections of the level togethor to create the whole level, to be able to let us grab the vertex points that make up the openings(ie: doorways, window, etc...) where portals need to go. We need to save those vertices in a clockwise order so we can reconstruct the portals as an alpha 0'd mesh ( or simulate them as a mesh if you have your own linepick method ) in our game to test if player passed through them or not. The data needs to save each portal info along to what section the portals belong to. The portals need also info on what adjacent section of the level that you would be able to see through it.
> At run time, we want the current section that the player is in and any ADJACENT section to have collision on ( ie: we use EntityAlpha 0 or 1 to keep collision on for the sections we want). Any sections that are not adjacent to the current section we use HideEntity command on them. So when a section becomes adjacent to the current section that the player is in, do a one time ShowEntity on it and then use EntityAlpha 0 or 1 when a current room's portal is in view or not. Here we need a little system to remmeber what sections are currently adjacent because once you move through a portal into another section we automatically get NEW adjacent sections. After you move into a new section, you need do a one time HideEntity on the sections that are no longer adjacent to you ( ie: obviously the section that you moved into to WAS an adjacent room, just make your code overide the HideEntity on that section because it's now the current room ).
> We need to know when we move from one section to another. You can either use a the LinePick command to use the old player location to point to the new player location and see if the LinePick passed through a "Pickable" portal. Here you would have a 2d shaped mesh in the 3d world for the portal and had applied EntityAlpha 0 to it. Or you can use you own custom linepick if you like. Just need some kind of way to see if you passed through the current room's portal. Once that check is made and the return value holds true that you indeed have passed through the portal then you can switch current sections appropriately.
Some notes:
[blitz built in camera view occlusion]
> I can almost hear someone say, "let blitz occlude adjacent sections by itself instead of alphaentity 0'ing them.". The thing to remmeber here is the level design. The doorway where the portal is may be out of camera view, but depending on how big the adjacent section is and it's shape, it could very well still be in camera's view. So when the current section's portal is out of view, do alphaentity 0 on it! (ie: less polys in view and less overdraw ).
[Amount of Portals for each section]
> As with normal portal systems, the more portals you use for the current section, the slower it gets. Here, we are just worrying about how many polys each section has (ie: the current section and any portals that are in camera view in which would show adjacant sections) and mabie how much overdraw there is since we are not doing any polygon clipping against the portals themself. As we place portals so it can not be seen by any other portal, the adjacent rooms may be big by design so I would keep the max of portals a section can have low like 3 or 4. Ofcoarse 1 portal is the best scenerio and I would imagine 2 portals for a section would/should be the average.
[outdoors!]
> Ya betch ya! If you have a bunch of hills, canyons, giant boulders, mabie with fog, and are unable to go above a certain height, you can make some wild terrain. Just make the outdoor terrain section big enough and wild enough so you can place portals without seeing each other. Almost like creating indoor sections except with no visible ceiling. I'm still thinking of that outside terrain like the unreal torny 2003 demo had. Or make you a jungle with perty trees!
> For flatter terrains, them rolling hills, I would use what I call a terrain pound system (ie: pound = # ). You would just simply have the 8 adjacent terrain section using alphaentity 0 or 1 depending what adjacent sections are in view or not. Since the terrain sections are square along the x and z axis, I hope it would be easy for you to determine if you walk off the current terrain section to another. ;) Ofcoarse, I'm thinking of good sized terrain sections here with the wonderful fog that we all know and love X) so we can't see pass the adjacent terrains.
[Integrating Indoor and outdoor]
> That's another thing that I'm "planning" to implement into my editor is a outdoor sectioned terrain system where I can cut holes in the terrain, move the outside model of the building approximally in the cut out hole area of the terrain and then move the terrain vertex points to basically connect or snap on to vertices of the outside model of the building or even be able to add polys to fill in gaps. Seamlessly, I can place the indoor section under this outside model of the buidling where you would have the a "doorway" where you can go in and out of the building at... [breath]... and save data for the indoor section's portal to know that it will connect/see/"Be adjacent" to terrain section. The terrain section will actaully have a portal leading into the building at that doorway. IT will know what adjacent section it will show/hide. More clearly here, the outside building is part of the terrain section and the portal that leads into the building is also part of the terrain section. ta da!
[NPC's & Multiplayer Players]
> Obviously our npc's and other multiplayer players would want to have collision when moving around specially when they are not in the main player's current section and any of current section's adjacent sections. Each npc and/or multiplayer player will act like the main player, it will have a current section that it is in. There will just be no need of alphaentity 1 on it's current section when we can not see them. If the npc's or multiplayers are in the main players current section or in a section that is adjacent to the main player's current section which is in camera's view view portal being in view, then there is no need to to on or off the collision for them. [note: you can work any other 3d objects that need to be move around in this way also. ahhhhh... physics]
[Forgot to add above: HideEntity on Adjacent Sections that are not in view]
> Well, without seeing how all this works code wise and in action, this could be a little problem to overcome for me. I remmeber in a portal system I was working on for the first project plasma community project when the player would back up into an adjacent section that was not in camera view and had alphaentity 0 on it to have collision on, sometimes I would catch the black empty space of nothingness at a corner of the camera view until I actually pass the portal or something like that. My portal should have been in camera view where it would have shown the adjacent section without the alphaentity 0 still be on for it. But, I probably did something wrong there. This idea should work though where when you pass the portal, do a showentity and entityalpha 1 on the new section so to be able to see it and not fall through the floor via gravity.
CONCLUSION( finally ):
> Little bit long, but hopefully someone out there can understand my jibberish here and can see that this should be a nice little system to use if so desired. It should be fast! I really do hope someone can make use of this method. I really do believe in it. It just taking me forever to get to it so I thought I would just share the info about this method. I have search high and low for any description of a simple basic method like this on the internet but just can't find anything similar. Probably just missed it and ofcoarse I'm sure somebody else would claim they done it before. big deal. If someone else implements it before I can, I really would love to see it!
> Whenever, I get my little editor to manualy place sections togethor, make terrain sections, gather portal information and make a demo along with source code for this method, I'll definetly release it for free for PD. Just need to find the time to do it! ...And I really want to do it! :\
* Feel free to discuss about this method and any other method here.