Tiling terrain
Blitz3D Forums/Blitz3D Programming/Tiling terrain
| ||
| I am messing around with tiling terrain that uses vertex alpha to smoothly transition between textures. I wanted to compare my findings with anyone else who has done this. For each texture in the terrain, I use a separate surface, with EntityFX 32 enabled. I set the vertex alpha values from an alphamap bitmap. I have to apply the terrain lightmap as a second texture to each of these surfaces. The use of the '32' flag causes z-order problems. The only way around this is to use an extra surface, just plain white, as the first surface in the mesh. The results look good, but it seems pretty unoptimized, since at the very least, you have to render the whole terrain twice just for the underlying z-order-fixing white surface. |
| ||
| . |
| ||
| Oh yeah, you can move one of the layers to the base and not blend it. I think I was doing that before, and I just forgot about it. I would just have every layer as a full terrain when editing, and then just delete triangles that are invisible in each layer when you export it. It's still probably 1.5X the polys of a regular terrain, but easy to work with. Cool. |
| ||
| . |
| ||
| i would have thought loads of people would be interested in terrain, it can really make a game look impressive |
| ||
| I think you are thinking in terms of a lot of small terrains, and I am thinking in terms of one big terrain. |
| ||
| . |
| ||
| . |
| ||
I recommend it. |
| ||
| . |
| ||
| oh please... :/ Good results Halo. I'm working on something like this as well. |
| ||
| . |
| ||
| Well, it's not what you say it's the way you say it... |
| ||
| . |
| ||
| yes you can, but let's not get into that, on on a public forum, as it'll be off-topic. |
| ||
| 'Swift', you need to end this unhealthy fixation with me. Wiebo, I think the next step would probably be to split the terrain into about 16 meshes, each with a high and low-res version, with maybe a third really low-res one. Then you go through and hide/show the different LOD meshes based on distance. I can't think of any way to process terrain meshes fast enough where you can LOD like Blitz terrains do. Once that is implemented, it should be possible to do much larger terrains with the same polycount. The mesh above is all at the highest LOD I would want, and it's 50,000 polys. Any bigger without LOD and it gets too hard to work with. |
| ||
| Looks real nice. And of course, 4 miles could mean anything - it's the resolution that matters. I've been thinking about something that could be added to some of these custom terrain systems... you could have a heightmap or whatever that determines the height of each point - PLUS a displacement map, that stores an X and Z displacement for each point - that way you could have overhangs and caves and such. In fact, since you can get a heightmap that only uses the R value of a heightmap, the G and B could be the X and Z displacement. Not sure how that would mess with LOD though. |
| ||
| I am not sure how you would calculate the 'displacement map' but that is an interesting idea. It mights be easier just to have a few big cliff prefabs that you can place to make thing a little more interesting. Anyone have any good ideas for UV-mapping cliff faces? At some point, the x/z uv mapping breaks down and textures get all stretched on mountain sides. I am thinking th only thing to do is group tiles for each hill and map them cylindrically. I would prefer to have to all automated, but don't see any way to do it. |
| ||
| Halo: I haven't been thinking about LOD yet. But your suggestion sounds good. I've run into the same problem you have with the UV values. I didn't have time to investigate though, as i am also working on an update of GUIde. |
| ||
| I am currently working on a Tiled Terrain system also. The way I do it is: I have a High detail mesh 54x54 which is my current location, then I place a ring of 8 tiles around that which are also high detail 54x54 tiles. Then I place a ring of lower detail 18x18 meshes around that, Then I place 18x18 mesh rings around those etc. Each ring is 3x larger then preveous one, it has to be to make a ring. 3x larger and 1/3 the detail. The 7th ring uses tiles Scaled to 2187, this gives me a viewing area of 118,000 units. If each unit represents a meter, I have a 118 km viewing area. I only need 57 meshes to create that whole viewing area. Also the rings don't have to be rendered that far out. If you are behind a hill you need only render one ring out. This makes LOD and Oculation easy to incorperate. At this point I still get over 330 fps in debug mode. I am done with the tiling and border patches between tiles. Now I am working on designing the height mapping part. Just loading a height map and applying it would be easy but, I don't plan on using a pre made height map, I want it created on the fly. That is why I designed a 3d terrain tile algor. which is in the code archeives. I used 18x18 meshes because they can be divided by 3 evenly. 18/3=6 6/3=2. This is important for aligning larger rings with smaller rings. I just posted this to perhaps give others an idea. |
| ||
| I'm happy that my worklog prompted people to start using this technique. At least, as far as I knew, these didn't start popping up until I mentioned it ... of course, I got the idea from UT2003. So whatever... Anyway, this is definitely the way to go for terrains. The tiling of textures produces MUCH nicer results than the default terrain system could ever hope to. And combined with vertex alpha? No contest. |
| ||
| Oh, and Halo, I wouldn't bother with the LOD personally. It's not going to make THAT much difference to your frame rate and will just chew up video memory that could be used for other things. And of course, there's the visual popping and floating issues ... just not worth it. |
| ||
| LOD makes a HUGE difference already, and I have even started lowering the polycount. If your terrain is one object, all polygons will be drawn all the time. If your terrain is multiple objects, only those objects in the view frustrum will be rendered. So already we only have to render parts of the terrain that are directly in our view, and within the camerea range. That can cut the poly count down to 25% what it was before. On top of that, and I haven't done this yet, each terrain piece gets a low-poly version that is used when the camera is far away. So you can crank up the poly count for the terrain chunks near the camera, and use really low-poly terrain for pieces in the distance. |
| ||
| Shouldn't. Unless the reason it's helping is something Blitz specific. Speaking in terms of Direct3D and hardware, LOD is generally considered a waste of time these days. |
| ||
| Well, Blitz totally lacks visibility culling, which is probably built-in to the Unreal engine terrain. Of course, the first part I described was just due to using separate objects, and I have not yet tried the LOD aspect. |
| ||
| "LOD is generally considered a waste of time these days." This is the reason for my terrain system. I lower the LOD before I render the scene and I always use the same LOD. This saves on cpu and gpu time. If I ever need a higher detail area I can add a new mesh on top of my terrain. Eg. A cave mesh. |
| ||
| No way man. I tried out LOD tiles. I have a 1,000,000 poly terrain, and with LOD I am only rendering about 10-30,000 polygons at any given time. |
| ||
| The number of polys isn't the only factor here. When you do your LOD, how much time does it take to lower the poly count? What kind of frame rate are you getting? Also what gfx card are you using? I ask, because lowering 1 million polys to 30,000 sounds awsome, if the math don't take to long. |
| ||
| . |
| ||
| . |
| ||
| Oh no! This guy says he won't help me! Whatever will I do?!! Please, how can I win your affection back? Because I soooooooooooooooooooo care!!! |
| ||
| . |
| ||
| Please refrain from the personal assaults. And no, I don't want to know who started it... |
| ||
| <sswifts antagonistic reply deleted> <skid's patience level decremented> |
| ||
| Yet, Halo can piss on anyone he chooses to. This must be what democracy looks like. |
| ||
| As Halo is clearly not going to be allowed to further repsond to my posts, I have deleted them. It's not fair for me to level accusations at him and not have him be allowed to respond to them publicly. If anyone wants to see the entire discussion to see why I flew off the handle at him, I saved a copy, and you can email me for it. |
| ||
| Anyways, the LOD works now. I haven't finished getting the cracks between the chunks perfectly flush, but should be able to get it done soon. My test terrain uses 1,000,000 polygons, and usually only renders about 26,000. Adding layers will probably push that up to about 50,000 polys, which I think is totally acceptable. Oh, and I am testing with the largest terrain I think an FPS game would ever need. I haven't measured or anything, but it feels like about the size of a big UT onslaught map. So if a mostly-terrain map needs to render 50,000 polys per frame, a smaller map with more architecture should be okay, too. I had to disable the layers while working out the LOD stuff. It looks pretty good:  |
| ||
 |
| ||
| Looking good |
| ||
| Ooo pretty. Tiling terrains is something I've worked on with varying degrees of success (or should that be failure). I found it a real challenge to create tiled terrains which appeared seamless. |
| ||
| It's not hard to make them seamless, just copy the base mesh. It was difficult to get the separate chunks of the terrain seamless. It's split into a big grid. |
   |