"Portals Revisited" - By: Pepsi
Blitz3D Forums/Blitz3D Programming/"Portals Revisited" - By: Pepsi
| ||
| 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. |
| ||
| Reference: PORTAL PAL??? |
| ||
| Pepsi, Good to see your back on Portals. Sounds like your covering all bases. My major concern with this sort of implementation is manually placing portals. I have done it and all I can say is that its very tideous. Not only does the Level Builder have to be responsible for placing portals (which sucks, I've tried it), the LB has to balance out poly counts for each section. These factors can really hender Level Building, especially if your a novice level designer like myself. Automated Portal Placement would be a huge plus. Others methods of optimization will be use LOD Mesh Switching. I'm not sure if portals will play a role in the control of LOD, but, its something to probable consider. |
| ||
| Rook, Reference: PORTAL PAL??? that would be here: http://www.blitzbasic.com/Community/posts.php?topic=34893 Frank, I think it's more up on user friendliness of the editor's GUI & controls which can make something hard or not. As an example, the most basic way I can think of to place a portal in a section is to pick a triangle around the doorway where the portal would go and then pick a vertex point of that triangle. After that, pick the next triangle next to the doorway and pick a vertex point of that triangle and so on. Keep doing that until you have selected all the needed vertices which would make up the portal in which would fit nicely in the doorway. Those vertices would be selected in a clockwise order to be saved out and loaded in the game so we can rebuild the portal mesh to use. Yes, that could get tedious, but to me it would be just as tedious in actaully making a level the way you want from a rough draft. I have figured out a nice method where I can actaully pick any given vertex, click the mouse button once and have a selection of possible portals in which wouldn't be that many portals made for just one vertex. Things like that can make portal placement a whole lot easier. For levels like quake or unreal levels where you have a limit of a size, I have another method where I can take a single mesh level and scan between placed portals to automatically create & seperate the sections and write out needed portal information. Just haven't code that stuff yet. Yes, I consider myself a noob at level design too. Heck, I'm happy if I can turn out something halfway descent with Maplet in which Gile[s] can save the day for me! :) All I can say is that it will take practice to gain any experience necessary to get use to portal placement just as with any other tool you that you would have to figure out and use. Automated Portal Placement is definetly something advance in the undertaking to develope. I'll simply stay away from it because I feel like I would do a better job with manual portal placements. This secluded portal method is more designed for manual placements to make sure that the portals can not see each other. Secluded portals for a BSP/Auto-Placed Portal System would, IMHO, add nightmarish complexity to develope it. If you can make such a beast, I would only imagine you being in heavonly bliss that you achieved such a task. Again back to level designing for us noobs, we just need to learn by experience that adding more "detail" to the structure of the sections, adds more polygons. I do think that CSG operations have spoiled level designers. I had decided that I don't like CSG operation based onthe fact that they do indeed create more unnecassary polygons and can lead into not creating correct geometry if not implemented right. It's nice to help speed up level building, but I think nicer level design can be achieved without it's blocky carving and filling. Just IMHO though as I'm not a pro level builder/designer or anything close to it... I will agree that LOD is wonderful at reducing frame rates. But I have decided for myself that I will not touch LOD algorithms unless mabie for character models. I have this mental problem where I get this passionate hatred in a game when I see the terrain pop in and out. No matter if I can barely see it in the fog. It shoots down whatever realism that non-lod terrains or non-lod indoor meshs brings. But, I'm just picky like that. Obviously, without LOD, the level designer needs to limit the number of polys for each level section to keep a healthy frame rate. Experience will rule the day. Those are definetly good points you brought up. Hopefully whenever I get this done and release the source code, one can add more to it like LOD systems and whatever else to fill the needs for his/her own project design. Right now, I'm trying to stick to the basics. Again, I really want to do this and get it done soon as I know people like to SEE the talk in action instead of listening to it. :) |
| ||
| Pepsi, I agree that the gui interface will definately make a difference for placing portals. I have a only brief understanding of portals, let any idea how I would design an editor for them. Look forward to what ever you come up with. Of Interest: An article on Automatic Portal Generation on GameDev.net |
| ||
| That article is pretty interesting. If I was doing a portal based engine in C/C++/DX/OpenGL I would definetly try that one out. I had attempted to do a BSP compiler in blitz, but got lost in the code (ie: lack of design docs ). It would be soooo much easier to do BSP stuff in blitz code if Mark didn't have something agaisnt C style pointers for Blitz. The thing that scared me a bit off the hand from that article is the tolerance bit. IHMO, the whole method in the article is getting to complicated to be feasibly programmed in blitz. AGAIN, that's my "IMHO". Anyhow, it would definetly be interesting if somebody did spent the time and labor to get all of that to work in blitz. But there is no K.I.S.S. in that... in which I am after. :) |
| ||
| Thank you... still learning about portals... and much more... (such a noob I am OY!) -RZ |
| ||
| This is probably a silly question but... Is it possible to write a portalling system using C and inline assembly, place it in a DLL and then call it from Blitz3D. Such a system would be awesome. Regards, Rogue Vector |
| ||
| Hi rogue, yes it is possible. IMHO, it all depends on how you want to build your portal system. You got to decide if it would be feasible to do it with a dll written with C/Asm depending on your portal engine design. Some things you may have to pass back and for to the dll is a bunch of polygon data that make up sections of the level. You may want the polygon data to see if your portals are visible are not down to pixel perfect level. Visible portal recursion techniques may take advantage of C/asm speeds. There's alot of factors to consider, but it's definetly do-able with dedication and time to do it. |
| ||
| I'm not sure it would be beneficial nor necessary to use a dll. Blitz Hide/Show Entity work very well. Additionally, there is too much tweaking needed dependent on the engine. IMHO, keep it Blitz. |
| ||
| Frank, I agree with that. For example, if an indie team was to implement their own occlusion system design for thier own project, they could very well design a dll implementation to gain speed in whatever areas they need it for. But in general for something that is designed to be used as a general system like the basic portal method I described above, it is very well left to be done in 100% blitz for tweaking/customization as you say. |
   |