levels
Blitz3D Forums/Blitz3D Beginners Area/levels
| ||
| I am doing soem sort of rpg. I want to know how I can get it so like it loads parts of levels automaticly without the user knowing! because the maps are very large I to like say a circle around the player shich is already loaded and as he moves forward evry so hurnred feet a bit more loads!! I want this as I think this is whats causing my bad frame rate |
| ||
| Well, divide it in smaller maps ..? (sized a hundred feet square) Does a lot of used memory degrade the framerate anyway? |
| ||
| I want to have it so it loads a radiout of a circle like it does in rpg you see it out side so it is hard to split it up into smaller maps and I want theem to lad as they walk without thwem noticing! +I don't want to mpodel lots of smallert maps |
| ||
| I've looked into this recently for my own needs and I came up with 2 methods. 1) Cut the world up into square meshes and load them as the player moves. 2) Create the world out of prefabs and use AddMesh to create the world on the fly. I was suprised that method 1 is less noticeable i.e. Loading the mesh from disc was faster than rebuilding the mesh from already loaded prefabs. AddMesh is a pretty slow command =/ As long as each mesh is large i.e. fewer LoadMesh commands I think it is satisfactory, there is a very slight pause ( a few millisecs ). I would like to know how other games do this in a totally seamless way though, multitasking the loading of the meshes maybe? Also I have yet to decide what factor to use to delete meshes that are far away. I may use distance but I'd rather base it on how much ram is available instead. |
| ||
| a great implementation of this kind of big world is Asheron call 1 (microsoft) the map in this mmorpg is really huge, but you can run from a part to another without any loading except when you enter dungeons or enter portals. i don't really know how they do the trick but it really inpressed me when i was playing this game.well it's an old game so the graphigs are a bit rough for actual standards :) |
| ||
| YehbI would like to get that affect any one know how it's done! |
| ||
| Well, do map parts that fit to each other as seperate meshes, load and uload based on distance, you unload on a greater distance than you load, pretty simple. Played Dungeon Siege? Here, also the crypts are entered unnoticed. |
| ||
| @eBusiness The problem I find with this is that it stalls your program whenever you load a mesh. It's only very slight but it is noticeable and can get rather annoying if your meshes are quite small. Games like Dungeon Siege seem to do this without stalling, Im assuming maybe their loading is done in a separate thread so as not to stall. The city in my game is about 5km squared and there is virtually no loading time at the start of each level. It is divided into 50*50 meshes, each one is therefore 100m square. Im wondering if I use molebox maybe the very small load time will be reduced to something unnoticable since it's already in the .exe? =) |
| ||
| The games that do that seemless loading of levels and such only load in a little at a time... It can be done in Blitz, but it ain't going to happen (be smooth and seemless) useing the Blitz loadmesh, loadtexture functions...meaning you will likely have to generate your own mesh and texture file formats and read them byte by byte per gameupdate...then use the Blitz addvertex, add triangle type stuff to slowly model the new areas as the game is running...actually a better way would be to just move unseen verticies and triangles (mesh deformation) as even the Blitz freemesh function can cause the program to stall... Still you will need to code up some sort of texture resource system (as load and free texture would also cause the program to stall)...so instead of freeing unused textures you game would just change them (writepixelfast a few bytes at a time)to make them into new textures and such... |
| ||
| Well, think you need your own loading function, if it's a problem, you'll need to make it so that it will load for a millisec or two per frame. But anyway, do any one of you use frameskipping? (Leaving out to draw a frame if the game is behind) If you do so I will guess you can load for about 100ms without making the game halty. |
| ||
| Perhaps there is a (albeit complex) way to time how much time you have remaining before the next flip, and just load whatever you can for only the time period slotted. |
| ||
| The newsletter said that some parts of Blitz Max will probably be open source, then it shouldn't be that difficult to alter the loadmesh function. |
| ||
| what about loading everything and hidemeshing it? then display only the stuff needed. I believe Hidemesh takes it out of the render pipeline. |
| ||
| You might run out of graphics memory, or restrict the game to ppl who have large VRAM on their graphics cards. Interesting idea about load in the texture, bit by bit. :) |
| ||
| I've got a decent idea on how to do this...but the game world geometry and textures would have to have restrictions...the end result would be something sorta like the Tomb Raider engine (but not exactly)...Erm...it would depend on how fast Blitz can free small meshes of less then 64 verticies and triangles...if it takes too long to do that (cause a visual hickup) then...well, the more Tomb Raider like the geography of the game world will have to be :P Basicly have a pivot named world...then parent that to a set of 64 pivots arranged in an evenly spaced matrix...each of these pivots is a parent to a mesh with one surface (each mesh haveing the same number of verticies, and triangles...64 surfaces, one for each model of the 4 by 4 matrix...64 256 by 256 32-bit color textures would be something around 16MB)...you can only see a section of 3 by 3 of these meshes at any one time (the camera stays at world center at all times)...move so far (translate the world pivot in the opposite direction) and the models outside of the 3 by 3 area get deformed, then their parent pivots get translated to the opposite side (effectively "building" a new section of the map)... You would need a bank or two to store file seek points and such (tell where in a file to find the mesh deformation data, as well as tell where to find the texure to surface it with)...maybe a bank that acts like a 3 dimentional array...you "slice" the game world into equal size chunks (sorta like a 2D tile map...but in 3D) each cell pointing to a specfic mesh and texture (the textures would all be the same size, but the meshes could be nearly any size/shape...as long as they have the same number of verticies/triangles and the triangles refrence the same verticies....however if Blitz can free such small meshs and such quickly enough then this wouldn't be much of an issue) Textures would be a pain, however by useing a sort of set resource file to store them all (each haveing a ID number or something)...textures could be stored as higher resolution versions, that you would reduce to working size when running...maybe store them as 32-bit 1024 by 1024 textures...that the game can scale down to 128 by 128 16-bit versions as it loads them (this way players with more videoram can use the higher resolution textures and such)...and by keeping track of which textures from the file are loaded, you can then check if it isn't already loaded and just apply it to the game mesh that needs it as it's already loaded and converted to the game settings ...also useing paletted textures would be a good idea, you could use an array or two to store the actual colors to writepixelfast with and by useing some sort of 2D array with a "lightmap" that exists in a bank you can bake a "lightmap" onto the texture as you write it pixel by pixel to video memory...(actualy this isn't a bad idea anyway :P ) If Blitz can free the small meshes fast enough then instead of useing a bank to store a 3D array pointing to the meshes and textures in a file...a oct-tree structure could be implamented...would do the same thing basicly, but allow much more variety in the game world geometry... |
| ||
| I thought about moving the world instead of the camera, the only problem is collisions won't work since they are all sphere to something. The simplest solution I have come up with so far is to convert the players x/z position to find what array element of the world they are in. The world is a 2D array of square meshes, e.g. World(50,50) If each mesh is 256*256 then the player is array element World(entityx#(player)/256,entityz#(player)/256). Then search an area of the array centred around the element that the player is in, the size of the area to search is based on the camera's viewdistance divided by the size of a mesh. PsuedoCode If player has moved dist=viewdistance/meshsize MinX=playerx-dist MaxX=playerx+dist MinZ=playerz-dist MaxZ=playerz+dist Loop If World(x,z)=0 then LoadMesh(whatever) Next Endif Deletion of the meshes is done in a similar way but this time only search the perimiter of a larger area again centred on the players x/z position. This means you aren't searching the entire 50*50 array every frame to calculate distance/visibility. Also the visiblility doesn't have to be calculated every frame, it only needs recalculating if the player moves into a new x/z array position. |
| ||
| I thought about moving the world instead of the camera, the only problem is collisions won't work since they are all sphere to something Then this is what you do...create a pivot for the player (a child of the game world...everything except the camera is a child of the game world)...when the player moves...move the pivot and check for and process collisions (updateworld)...then move the world so that the player pivot and camera are at the same location...render world and flip... |
   |