Portal Engine
Blitz3D Forums/Blitz3D Programming/Portal Engine
| ||
| Is there any good portal engine source avalible for free/purchase? Im trying to figure out how to do a very very large exterior portal based landscape , and i cant seem to nail it perfect. So im looking to see if anyone has yet? |
| ||
| Baud, There is a small but very efficient demo that comes with Quill 3D. I don't know how it is on exteriors though. Also there is a portal demo in the archives - I think. IPete2. |
| ||
| i thought there was too. But the only portal demo there is is actually a texture scrolling map on a cube. Im looking for a portal in regards to maps. Ill check out the quill 3d demo. thx. but i doubt it has any source. |
| ||
| Why would you want to use portals in an outdoor environment? 'Some kind of outdoor maze, perhaps? Just wondering... |
| ||
| i know its kind of inefficient. But i wanted to figure out how to do an infinite landscape. I want to load square meshes that fit togeather as a single landscape. If the player is on the center of a landmass then the areas around that square/landarea are loaded and rendered. [][][] []P [] [][][] I know that portal systems use the feature to only load the next room etc. if it is visible through a door. But I was thinking that i might be able to leverage some code to do this by using a portal style system that only loads the areas within a preset 'visibility range'. This would allow a user to walk infinitely on a mesh terrain. I can add custom meshes whereever i want etc. Im having a bit of difficulty making it efficient though. Right now ive got the concept in progress, but the fact of the matter is that i am looking for some reference material to see how others have done similar things. |
| ||
| I believe there are some infinite terrain samples out there somewhere. Might I suggest...building a lookup table that assigns each section of terrain a grid number. Then, taking the player's position and viewing range and use that to determine which pieces of terrain should be seen. If player is in grid space [x,y] then (depending on range) draw... [x-1,y+1] and [x,y+1] and [x+1,y+1] [x-1,y] and [x,y] and [x+1,y] [x-1,y-1] and [x,y-1] and [x+1,y-1] ...or something like that. |
| ||
| good call IT. I had come up with a similar conclusion. But the hard part is the checking to see if the players position is within viewing range. This becomes difficult because if i am using an array or a collection of types, the more landareas that i have, the slower the search is. Have you seen any infinite terrains examples that i might be able to look at? |
| ||
| IT I found a good source for this idea. I think i may take a look at how this is done in this demo. I want to use meshes not height maps and i want mine in 3d (im asking alot) but this is a good place to start for my own purposes. Just thought i would post a link http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=makakoman04012003155225&comments=no |
| ||
| If I could suggest creating an invisible grid made up of quads, four vertices(a square) ... and use it as a parent object for each landscape or terrain patch in the grid. So you might have a grid like so .. 123 456 789 9 quads ... start off by having each quad hidden ... so all child entities(the landscapes and trees etc.) are hidden from being drawn. use entityinview() to see which grids or terrain sections are in view . then unhide those the grids that are in view. and that will unhide all the child entities This would be essentially be the start of a quadtree and can be extended by adding more grids, or further sub dividing the parent grids into smaller ones .. |
| ||
| I guess if you want a variable range, you'd need to have a function that would determine which tile could be seen, based on the size of each tile. If the player is located in grid tile [x,y] (anywhere in that tile), and the size of a tile is 256 square, and the range is 1024, then the function would need to return a list of tiles around that position with a radius of 4 (perhaps 4+1). Come to think of it, you could probably find a filled circle draw function somewhere that would do the trick. |
| ||
| Codemonger Good call on the unhiding entities. I may use a hybrid of that idea. But i really want to load the meshes as the player gets closer to them, rather than having them already loaded. it would save on memory and allow higher meshpoly counts in smaller areas. LT entitydistance would prolly be the best bet to check to see if anything was in view. I will automaticly load one more tile around what ever tile the player is sitting on. IE the diagram: [1:1][2:1][3:1] [1:2][ P ][3:2] [1:3][2:3][3:3] all of the terrain/land squares aroung the player would be drawn. I think the most difficult part about this is making sure that i can check *which* ones should be drawn. To do this i would certainly need an index or a lookup process. Its really too bad that blitz3d doesnt have db support. This would be an excellent database solution. |
| ||
| I figured (as you mentioned in your response to Codemonger) that you would be generating the pieces of terrain or loading them or copying them from a reference. The problem with using EntityInView on a quad is that it would not always be in view when looking in that direction (if the player was say, tilted up, looking at a mighty mountain peak!). I should point out that EntityDistance would also require that the object exists, unless you use something like a pivot as a stand-in. I believe the distance check would be slower (but simpler) than doing a look-up, but not much. The brackets diagram you typed in will work only if the terrain pieces are large enough to encompass the player's view range. Lastly, I would recommend against worrying about which ones would actually be in view. I believe Blitz (or DirectX) throws those out anyway, and besides, turning the player around in a circle would result in the constant loading\unloading of terrain pieces. Ciao |
| ||
| So loading lets say 255 to 1024 instances of large terrains but only rendering 9 at a time would cause no noticable loss in redering time/memory? I find this somewhat hard to beleive. (that wasnt a critisizm btw). I will ahve to experiment with some loading of terrains. I will post what i find. Thanks for the info. |
| ||
| Why even bother hiding/showing meshes if your only criteria is distance? The camera will automatically cull distant meshes. |
| ||
| but the meshes are still in memory though. Wont that cause lag... i suppose the difference i negotiable considering that it would take time to check for what meshes to load |
| ||
| I don't know if anyone realizes but it's the amount of data that is sent to the rendering pipeline that causes the infamous slow downs ... Blitz is not slow, but you cannot shovel huge amounts of data down the rendering pipeline, you have to cut as much out as possible ... that is why you see the 2 GHZ computers slowing down when they shouldn't be .. too much data being sent to the rendering pipeline. So if I where to write a terrain algorithm I would probably do the following (for terrain only): -------------------------------------- create 4 ^ X terrain meshes (or whatever you want to use) and place them together so they make up one large grid of terrains. We will use 4 ^ 3 (64 terrains total) 1) Hide all terrain entities -- (they are out of the rendering pipeline) 2) divide your map into 4 invisible bounding boxes (alpha 0) to take into account what LT said about looking up etc. ----- | | | ----- | | | ----- these are your 4 parent entities ... they can be really huge ... then you add another 4 bounding boxes to each parent entity so it looks like a heirarchy --- you stop when you have created enough bounding boxes to cover the amount of terrains you have.. so for 64 terrains it would go something like this MainBoxes (1 = size of 16 terrains) 4 total SubBoxes (Parent is mainBoxes) (1 = size of 4 terrains) 16 in total MiniSubBoxes (Parent is SubBoxes) (1 = size of 1 terrain) 64 in total (one for each terrain) Terrain (Parent is MiniSubBoxes) So now we make sure everything is completely hidden and the alpha for all bounding boxes are set so they look invisible .. so lets start our render loop... Pseudo code : ' use a nested loop for rendering and checking do for i = 1 to 4 ShowEntity(MainBox(i)) if entityinview(MainBox(i)) then for j = 1 to 4 ShowEntity(SubBox(j)) if entityinview(SubBox(j)) then for k = 1 to 4 ShowEntity(MiniSubBox(k)) if entityinview(MiniSubBox(k)) then ShowEntity(TheChildTerrain?) else HideEntity(MiniSubBox(k)) endif next else HideEntity(SubBox(j)) endif next else HideEntity(MainBox(i)) endif next loop --------------- anyway that is some pseudo code and the arrays are all screwed up because I did not want to make it super messy for anyone to read ... but you might even be better using some of the parent/child command to travers the nested boxes.. also remember to hide all terrains the you showed after you render. |
| ||
| OK the code looks really shot because I cannot tab it out to look nice. So, if you need a better interpretation let me know ... |
| ||
| Hmm, I'm not sure where we've crossed wires, but I don't recall saying anything about loading 255 to 1024 instances of anything. The meshes in memory shouldn't cause lag, btw. Loading them off of disk probably will, though. I believe it's just a matter of whether or not you need that memory for other things. If you plan to make a game vast enough to require an infinite terrain, it sounds like you'll need all the memory you can save. |
| ||
| my head hurts...lol So many different ways to do this. So little time...lol Im gonna have a good crack at this tomorrow. The caffine is starting to fade. Thanks for the suggestions guys. As always the forums come through. |
| ||
| That's an interesting approach, Codemonger, and yes, much like a quad tree. AND, strangely enough, it is precisely the approach I am considering for hierarchical lods. It can be applied to terrains as well - fancy that! |
| ||
| LT it would be great to see LOD added to the above in the form of mesh animations ... so it would be a matter of getting down to the terrain patches that are in view, then check the distance, and then change the animation frame of the mesh to a certain detail ... Frame1 - high detail Frame2 - medium detail Frame3 - Low detail etc ... I don't know if this can be done, but it would be probably the fastes way to change a mesh's LOD ... |
| ||
| Baudspeed, just out of interest (from reading these posts) - what kind of terrain are you looking at creating ? 3D object based ? or with the inbuilt terrain commands ?? I've been thinking about the same problem (portals), for my next 'indoor' project These days it seems most new landscape games seem to be dividing the area up into sections which the player cant see out of, Morrowind and the new Pirates of the Caribbean spring to mind - but it has to be said, even though the detail in each section is very preetty - there are times when you really wanna see a view that stretches far and wide !. I'd be very interested to know how you get on with your test coding... |
| ||
| Baud, I don't know if this helps... We built a massive outdoor scene, you could travel approximately 146,000 in the z direction as well as traverse the model any way. Blitz coped fine (certainly on a high end PC 2.2ghz 1gig ram) but it coped fine. Halo is right, what the camera doesn't see doesn't get rendered. We had two cameras on this project looking at different things (the second camera made a huge difference to the rendering time). The biggest problem we had with this type of model is that the further you travel away from the origin, the more errors creep in. HUD stuff judders if attached to the parent camera, etc. I would suggest you look into tiled terrains, There are demos around the forum, Sean Swift has a terrain tile engine somewhere... I think infinite terrain has been discussed but I'm not sure who's had a go at coding it. I don't think portals would be very effeicient - you'd need a lot and someway to hide the areas not in view (which the camera does anyway). You can always use camera fogging (hah! ;) IPete2. |
| ||
| Baudspeed, I see you found my demo of infinate terrain. What about it doesn't work for you? Maybe I have fixed it and can help you out. Regards, MK |
| ||
| mak, I was looking at it. Great work btw. Its close to what i am looking for but i have decided to use meshes instead of height maps due to wanting to be able to add features such as tunnels or caves. As for the reuse of your code. I need to be able to apply unique terrains/meshes. So if i had a collection of 50 different terrain/mesh land squares, it would organize them according to how i have designed the world. ie organization of meshes/terrain numbers as follows [2][5][12] [33][2][21] [31][4][9] i was thinkin of just building a huge array with the mesh ids in them, but the difficulty is then figuring out how to see which ones will show. (currently working on a solution which uses the current user position as a lookup) Your demo (albeit a great demo) only reuses the terrain. Even if i did this, i would still have the issue of how to check to see which game world objects (castles trees) need to be rendered. BTW you may want to check the type you are using for handling the compass. Change the feet persecond to a high value, and start walking. Eventually the compass does some wonky stuff due to type conversion/overflow. Thx though. It certainly has inspired me. |
| ||
| I though of a good idea from looking at this. It would be a bit tricking but would work. All you really need to do is the knwo the cordinates of wher ethe terrains begin and end. Setup a if statemen to check when cordinates are greater then. when they become grater then it loads and unloads a terrain. That shoudl work theoretically. you would need an if for both the z and x cords. |
| ||
| Zephar123, thats pretty much my solution Alright guys. I have everything working. My terrains are a square 3d mesh that sits at 0 coordinates. I figured out how to get them the correct size without scaling. WHen a player walks in a direction, the terrain in front of them continually 'pops in' the memory bank is checked to see if a key that has the same name as 'X:##,Y:##' is there. If it is not, then it uses the default terrain. The size of 1024 units btw is just a bit too small but it works and the player cant see the outer edge too much when everything is scaled appropriately. I think i might clean up the code and release it. It gives a bit of jitters when the meshes load. So i cant do a real time unlimited world. And yes i have noticed that there have been some odd effects during huge numbers (ie really really far away from 0,0,0. But thanks for the help guys. It certainly was worth the effort to build it. Doubt i will use it though since the load of a new mesh causes the 'hitch' effect. I might end up preloading meshes and cloning them. Thx |
| ||
| Why don't use a precalculated VIS using linepick and poly picking ? Then you will use a combo of Clipping, EntityAutoFade, and Hide/Show with the precalculated data, and that should do the trick for most games. |
| ||
| zurk good suggestion, but that would work for things only loaded and line/poly picking is slow. I want to get away from preloading all of the landscape. That would be a huge memory hog |
| ||
| Baudspeed, I am just starting out in Blitz3D and I am also interested in an infinite terrain, using tiled mesh terrains. And I would be very interested in seeing your source code. I have been debating wether to go with using tiled meshes of tiled terrains. Terrains do have the advantage of all the commands available for them. I was interested in how you deal with moving over the landscape. I want to create a 3D world that is created entirely on the fly including landscape, plants, creatures, peoples. All from a random seed value. So anyone that enters the same seed value will get the same 3D world to explore. I was inspired by the game Carnivores 2. Anyway I sure look forward to seeing your code if you do post it. No matter how messy it might be. |
| ||
| Abba Rue, I like the random see idea. I still have yet to pick around with the code to clean it up. I think i might do that this weekend. I find the real time loading of the tiled terrains is a bit hitchy, and i was going to assign my game objects to each terrain, but for instance if a character is being chased across the terrain onto another square, it needs to be reassigned. BTW, i solved the 'out of space' issue by allowing a default terrain tobe loaded. Ill try and document it to death and see what people think. maybe it can help someone else out. I think what i might do is modify the code later so that it loads up a huge area initially as you travel so that it mimimizes the hitching, and shrink the tiles so that they load faster and cleaner. BTW guys thanks for all the help. This has been a very good thread to read and think about. |
| ||
| I placed 4 terrains together with camera set at the corner that joins all 4 but I was not able to see into the other terrains until I crossed into them. Is there a way to see into 2 or more terrains at once? |
| ||
| EDIT: I decided to remove my posts on this subject because I feel that I should have something to show, before commenting on other peoples implementaton... The reason for thinking that people are making their terrainsystems much too advanced, is propably due to my own programming style being more focused on dividing the task into as simple parts as possible, and thus not really understanding the ideas discussed. Also, the 4 PC's mentioned were not enough to actually say that it worked perfectly... It should have been tested on a variety of different harddisks, memory configurations and CPU speeds and brands. So, I have decided to do more work on my current terrainsystem project, and then offer a public test, when it reaches a state where I feel it works. That way, we can discuss like for like and actually know what works. Sorry, I normally don't condone removal of posts, but I am not sure that I know what I am talking about here, so I will go investigate and report back when I feel confident in this area. Andy |
| ||
| andy i was trying to get the info on what terrain was next quickly. Id be interested in seeing your implementation if you dont mind. It certainly sounds similar to mine but if you dont have hitching on the loading of the terrains etc. it certainly would be better than my implementation. It also sounds like you are doing landscapes rather than meshes too. which can get sticky when you need to add things like destructable items at the appropriate heights. How did you handle that? Ill post mine near then end of the weekend. It needs some cleaning. anvil@... |
| ||
| EDIT: See above Andy |
| ||
| I just posted my source in the code archives for anyone to tweak with. If anyone has any implementations of something similar i wouldnt mind compairing notes http://www.blitzbasic.com/codearcs/codearcs.php?code=801 |
| ||
| (just read this topic) huh. that quad tree stuff is what I'm using to do my custom collisions in my physics system. It makes it alot faster with high detail. Oh yeah, and Baudspeed, you might want to see how well your game holds up so far away from the origin. sometimes things go wierd. |
| ||
| yeah i have noticed that effect in other occasions. any idea what causes odd issues like this? is it the math blitz uses? i was thinking rounding errors on large numbers' |
| ||
| @ Baudspeed: I was wondering if you had done anymore work on this project since you posted the source code. |
| ||
| Abba None. ive been to busy with contracts and trying to keep myself fed lol. hopefully after this contract is completed i will be able to work on this and a few other projects. |
| ||
| >yeah i have noticed that effect in other occasions. any >idea what causes odd issues like this? is it the math >blitz uses? i was thinking rounding errors on large >numbers' You might want to look here: http://www.blitzcoder.com/cgi-bin/ubb-cgi/postdisplay.cgi?forum=Forum4&topic=000352 Andy |
   |