Thinking about terrains (again)
Blitz3D Forums/Blitz3D Programming/Thinking about terrains (again)
| ||
| I happen to like Blitz's native terrains, but they have their drawbacks. Mainly though, I'm always reading how they're slow. Does that mean slow to render? My main question being, if I were to create my own system with LOD and everything I need, assuming it's tightly coded, will custom meshes render quicker than blitz terrains? My second question: I want to make a terrain system that calculates terrains given a certain amount of key points (where the terrain smoothly goes through all those height points). I had a go at creating a function for that before and it stumped me. Before I embark on it again, is there an algorithm already documented somewhere? |
| ||
| Blitz terrains are good for crappy video cards, because you can have very few polygons in the mesh and still have some decent detail up close. In the castle demo, the terrain looks kinda smooth, yet is never made of more than 768 polygons. But that terrain is just rolling hills. If you want an bumps, or hills in the distance you need more polygons. Blitz terrains start to really cost you framerate when you get up into a few thousand polygons of detail, and that's still not much detail. If a detailed terrain is what you want, then custom meshes will get you much more detail. But if you want good view distances you'll have to make your terrain out of tiles and have several levels of detail for each tile of terrain. My terrain system uses that method. Multiple static levels of detail for each tile. I allow one texture per tile, so the texture can be rather varied too, though if you really want high texture detail you'll need to use vertex alpha and multiple surfaces so that you can tile the textures more than once per tile of terrain. The surface count is what limits you to large tiles though, so if you did something with vertex alpha you'd want to limit yourself to no more than 4 textures per terrain tile or less, and you'd have to make the tiles 4x as wide to keep the number of surfaces the same. "My second question: I want to make a terrain system that calculates terrains given a certain amount of key points (where the terrain smoothly goes through all those height points). I had a go at creating a function for that before and it stumped me. Before I embark on it again, is there an algorithm already documented somewhere?" There are definitely algoithms to do that, but I don't know a specific good one that can work just with points. A bezier surface for example would require additional control points at each point. Four I think. There's something called nurbs... dunno how those work. Tehn there's perlin noise... I have a function for that int he code archives. It occurs to me that you could define the points for one of the lower octaves... and so define only a few points, in a grid, and then allow the perlin noise function to fill in the higher octaves of data based on that. I forget if my function calculates things the right way round for that though. You'd need to divide the height each time and I think I multiply it, so I work from the high octaves of noise to the low octaves. My perlin noise function also uses a cosine interpolation function for bilinear filtering... You might be able to use cosine interpolation to interpolate between your heigts somehow. Imagine a single wave of a cosine curve. The height of the start of the curve, above 0, is your first point, and the height of the end of the curve, below 0, is the height of your end point. Assuming the second point is lower of course. That gives you a smooth curve, but it wouldn't look very realistic. Neither would any sort of bexier curve or spline surface really. Not noisy enough. That's why I use perlin noise. |
| ||
| http://www.dyvision.co.uk/ale.htm ;) |
| ||
| All you want to know to create your own Terrain System http://www.vterrain.org/ |
| ||
| ;- |
| ||
| ALE landscapes are ALWAYS the same size - 64x64 Blitz units. The center is at the origin (0,0,0). Thus the landscape extends from -32,-32 to 32,32. When in 'walk' mode in ALE (Options->CameraMode), there is a slider in the menu labeled "WALK HEIGHT" that allows you to adjust 'eye-level'. Next to the slider is a readout telling you how high 'eye-level' is. If you need to scale up/down to suit your own engine, you just scale these values by the same amount. |
| ||
| I think I need to throw in my 6 pennorth here. My own requirements were a huge terrain with hills, but visible well into the distance. I ended up using a 1024x1024 heightmap, with a 1024x1024 colormap above it, then scaled x20. This effectively gave me a 4 sq kilometre terrain, with a view of a least 1 kilometre. FPS was very good, and only began to drop when I added lots of trees or grass. I _did_ ask the old hands at the time, and they said that Blitz terrains are amazing efficient if you want real size, and Mark S had already coded in intelligent LOD into the system. I certainly can't complain, my terrain has exceded the dreams that I first had. The only thing that remains outstanding is that I can see that I will need 'proper tiling' in forthcoming projects, and obviously I'm hoping that BlitzMax will include this in its terrain system. If not I'll be looking at sswift's system for this functionality. :) (I wish we could start a separate Blitz Web Site section just about terrains. I think the subject justifies it.) |
| ||
| If my terrain system actually sold decently I might have written an even better one by now with much greater texture detail and fewer seams... But it hasn't, so I haven't bothered experimenting with more advanced methods of terrain rendering. Also there's the little issue that I don't have an interest in making a full on terrain editor, which would really be neccessary if I were to do anything more complicated than the method I'm currently using. Of course maybe there's something people don't like about my terrain system, and that is why it hasn't been selling all that well, but people don't often email me and tell me that they don't like this or that about it. |
| ||
| Sswift, with the crappy demo you have for your terrain system, this is no real wonder. I don't know why but your Demos never show of the real power of the systems, they look like 10min "use of command" tests. The same goes for example for your really nice foilage system which has not even a description on which base the foilage can be positioned and predefined by the programmer ( or if it is even possible ) which would be needed to create a real app. I really like the Shadow System and it is quite powerfull but the demo is just a joke and won't convince anyone to buy it as the situation is far from "real use" |
| ||
| Or you can see at my free terrain mesh system http://www.blitzbasic.com/Community/posts.php?topic=34168 And this system use a child system occlusion A demo of my system by Seyhajin http://www.blitzcoder.com/cgi-bin/showcase/showcase_showentry.pl?id=seyhajin07122004191942&comments=no Or my demo (with a specific occlussion system) http://www.blitzbasic.com/Community/posts.php?topic=33472 |
| ||
| ;- |
| ||
| The only thing that could be done is to develop a system with several terrains attached side by side - so you could even give them different heightscales. ALE already has a 'make tileable' function. Any 2 landscapes with the function applied will fit together seamlessly. :) With enough RAM you could have an entire planet made of entirely different landscape 'tiles', each one 64x64. Or, you could just repeat the same tile(s) over and over and have an infinite landscape like in Torque. I've done it already :) |
| ||
| Damn, I didn't know about the 'make tileable' function. I'll have to try that in the demo. The texture painting features in ALE are pretty sweet but I didn't feel like that was important enough for me to purchase the app; if 'make tileable' works well that feature might be the tipping point for me. |
| ||
| ;- |
| ||
| 65*65 = 4225 so it is up to you how many tiles you use and how many polygons you will have. averange will be 16 * 4225 = ~67k to 36 * 4225 = ~170k |
| ||
| ;- |
| ||
| It all depends on what the lanscapes actually look like. If you only used one layer, all the rest are culled at export. More detail=more polys (as always - there's no way around it). ALL invisible polys are culled for you at export though. As for LOD, that's something that needs to be implemented in your own engine. Even if the ALE editor *did* have realtime LOD, it wouldn't help your engine would it? Or do you mean mesh polygon reduction for exported models : Don't forget the .x export from ALE. It collapses the 'layers' and bakes the result into 4 textures for you. You could use these as 'far' LOD tiles and the fancy .b3d ones as 'near' LOD tiles. :) Or export a heightmap from ALE and mix/match Blitz terrains and ALE landscapes. |
| ||
| i prefer custom meshes, i can make giant landscapes in lightwave that are only about 1k polys but look perfect. |
| ||
| Well I prefer MY terrain system (private) build over the Blitz terrain. Not too slow whe you add clipping and shadow maping. Tiling... Ancient as 2d vgames and quite useful through the ages, and usualy misused. Terrains over custom meshes: Clipping is faster. Easy to apply shadow maps. custom meshes over terrain : 100 times more texture control (.X) more polygon control. |
| ||
| I would like to investigate spherical. I found a small sample in the "Samples" Folder of the Blitz install. Texturing these Spherical Terrain seems like a bear, but The terrain is neverending for all intents and purposes. Does anyone have insight on this area? Regards, Eric |
| ||
| Not only is texturing them a bear, but creating heightmaps for them is as well. Would also be difficult to LOD on... and you'd have to model proper gravity in order to keep the player stuck to the terrain. The hardest bit is the need for a custim editor really. Making a geosphere and deforming vertcies isn't too hard. |
| ||
| ;- |
| ||
| Yes it's true, it's not really good to have one system who is flexible as possible to offer for as manue different programmers. I have download many source code (Quake 1&2, Half Life 1, Descent, free space etc... all this code are free on the editor site) In all these game there is no generic engine in anything. For example if I take the case of Lotus particle or my particle system (EPS), it is in fact a aberation ,because there is code and test which makes spends time CPU for possibility that the game doesn't need. After having looks at the source, the engine answers exactly has a need well precis. It goes from there from same for an engine of terrain, definis initially your need and after you will be able to reair or write your clean system ground. My Terrain system is for the maps whar are not very large for multi with vegetation... This is my point of view is that the lib generic is useful has anything... |
| ||
| ;- |
| ||
| ;- |
| ||
| Looks very nice. Sad that it never went any further :( Started on something similar but with GeoMipMapping as target but my algo has still some bugs in generating the tile seams and inner part out of a height map ( which have a different detail degree ). So I still have this boring T-cracks. |
| ||
| ;- |
| ||
| I'm sure ALE is nice, but I spent months making Total Terrain, so I'd be silly not to use it! TT is actually pretty well featured, but I'm starting to think about my game now rather than a terrain editor.For my purposes right now, blitz terrains are perfectly workable, but I do want to creat my own system at some point... |
| ||
| ;- |
| ||
| "Removed" |
| ||
| ;- |
| ||
| You shouldn't have to work around it, this problem should have been fixed this instant it was recognized (and I highly doubt it was noticed years after). Although I can probably find countless worse answers (by myself, no less), it isn't exactly the most intelligent way to handle the situation. It'd just look bad. |
| ||
| ;- |
| ||
| Actually that post was just a bad joke. I don't think that bug is going to be fixed soon. I have asked questions about this type of thing before. I gave up on using Blitz's terrain function 12 months ago. Mainly because I didn't know why the opposite edge of a terrain always looked so strange. I wasn't aware of the fact that Blitz did a wrap around of the pixels. I have designed my own Terrain engine that allows a viewing area of 60 km in each direction and renders at a frame rate of 320 frames/sec. So I don't have any use for blitz's terrain engine. I am building an entire planet that uses it to display a 120 km area at a time. Of course that is only if you are standing on a cliff overlooking a large area. Most of the time a viewing area of 13km or less is enough. And the main playing area is about 150 meters wide with a res. of 1 meter per vert. That's about the size of an average city block. From there the viewing area gets less and less detailed the farther away it gets. And I still would like an answer to this matter. Has anyone tried using a snapshot idea as a backdrop for a terrain. I would like to incorperate a snapshot idea into my terrain engine so I don't have to render as far a distance so often. Of coarse I mean applying it to a sky box. PS. In my experiance with Blitz3D I have found that I need to do a lot of work arounds. There is always something that Blitz just doesn't do the way I need it to. If I didn't look for work arounds I couldn't use Blitz, or any programing language for that matter. They all have there short falls. |
| ||
| The terrain system of blitz is to slow anyway ... you can have 100k poly and more onscreen with static meshes and you will still be faster than with 6k blitzterrain ( and you won't have Blitz Terrains pop ins as well) |
| ||
| When you say, "static meshes" - is that a particular type of mesh? If I create a custom mesh within the program, does that count? Or does it have to be a loaded-in mesh? (Is there a difference?) Reason I ask is that I would like to generate the terrains from algorithms rather than heightmaps (maybe). |
| ||
| Once you have a handle on a mesh, the system doesn't care were you got it. Weather you load it or create it on the fly a mesh is a mesh. The number of verts. and Surfaces the mesh has effects the rendering speed. Not were it comes from. I think Dreamora means a static mesh vs an animated mesh. |
| ||
| As to the snapshot idea I think SSwift tried it some time ago. I can't remember exactly how he said he did it now, but I think he got it working to some extent. |
| ||
| I used a camera with the near plane set in the distance to take snapshots of distant terrain. But I never really got it to help speed up rendering because there's no way to render alpha information into such a texture. |
| ||
| ;- |
| ||
| For adding things like a city or village. I thought of using a large box that is textured with an image of the city from the outside. The box has images of gates on each of the 4 sides, then when you step up to a gate, the box is replaced with the city inside of a box. So when you enter the city you are looking at an image of the outside world projected on the inside of the box. The image is a high wall with the sky behind it, maybe some high mountain peaks. The rest of the box is filled inside with your houses and other buildings. In turn your outside terrain is replaced with an inside structure. Smaller buildings on the main terrain could use a simular idea but on a smaller scale. And the outside images would only be seen through the windows. My terrain engine uses a factor of 3 for each level out. It has a central mesh surrounded by 8 meshes of the same size. (look at the numeric key pad the 5 key surrounded by the other keys.) Then this area of 9 meshes is surrounded by a ring of 8 meshes, each the size of the center 9 meshes. (again looking at the numeric key pad the 5 key represents the preveous 9 meshes. I continue this concept outward using rings of 8 around the center, each 3 times coarser in size. ( Actually I should rephrase that: I start with the coarser set of 9 meshes, and then render the center mesh further to get a mesh 3 times finner in detail. This I do down to the point I have 1 meter between verts. I could easily go another lever to get 1/3 meter res. but I stoped at 1 meter.) That is how I get an area 120km by 120km with a framerate over 300 fps. My system specs are at the bottom of my posts. I have all my seams joining smoothly without any cracks, But were I still am having difficaulties is moving this large multilayered mesh smoothly across the planet. As I walk the mesh has to be set to the new height values of the next section. This would be easy if the mesh used all the same distances between verts. But the rings of lower and lower res. make it more difficult. I render the finer res. areas using a form of fractals, that always gets the same values for a given vert. So my whole planet is rendered from a small 512x512 height map. (Actually 486 by 234) The planet I have designed is 9,565,938 meters around the equator. By 4,605,822 meter from North to South border. I am staying away from spherical stuff though. So my North and South borders are oceans that end at a wall of ice. Maybe someday I will create a circulare north and south poll area but not now. It still needs work, mostly the right math to keep it rendering fast as the mesh moves. Any ideas about how best to do this? |
   |