"Am I missing something?" or "why Blitz3D terrains are nearly useful!"
Blitz3D Forums/Blitz3D Programming/"Am I missing something?" or "why Blitz3D terrains are nearly useful!"
| ||
| I am new to Blitz3D, having moved over from DarkBasic Pro. As the title of this topic says, my problem is that I cannot see a way of applying textures to the surface of a terrain, other than the global 'slap it all over' entity texture. I don't understand why a really useful feature such as being able to load a heightmap to create a terrain, is let down by the fact that they are pretty much useless as you can't texture them properly. Or am I missing something? I have a 256x256 heightmap to create the terrain, and a 256x256 heightmap to create a water terrain. What I wanted to do was have another 256x256 image to determine the texture numbers to apply to the appropriate 'cells' on the terrain. |
| ||
| Look through the code archives and look through the showcase at Blitz coder. There should be some alternatives to choose from. Personally, I use the terrain system by sswift: http://www.blitzbasic.com/logs/userlog.php?user=963 It is well worth the modest $$. |
| ||
| "I have a 256x256 heightmap to create the terrain, and a 256x256 heightmap to create a water terrain. What I wanted to do was have another 256x256 image to determine the texture numbers to apply to the appropriate 'cells' on the terrain." Blitz terrains are a single mesh with a single surface which dynamically changes shape. As such, only one texture can be applied. And, because they use the ROAM level of detail algorithm, there are no fixed size "tiles" on the terrain which can be used to apply different sections of a larger texture to the terrain with. Blitz terrains are not better or worse than Darkbasic terrains, they're different. DB terrains have to be tiny, or low detail. Blitz terrains on the other hand can be smooth up close, yet still huge, because they use reduced detail in the distance. Unfortunately the tradeoff is that you have to stretch one texture over the whole terrain. However, this isn't neccessarily so bad. It depends on the game. You can actually place several textures on the terrain, one in each texture channel. But what you do then is you have one huge one which contains the base color and lighting, and one smaller one which you TILE, which should be bright, with roughness, and that makes the texture look rough up close. In this way you can get a desert looking terrain, or a rocky alien planet, or something approximating dirt and grass. Add a plane for water, and you've got SOME variation. Not a ton, but if you need three miles of terrain and you don't want huge jagged polygons, it's better than DB terrains. Then there's my own terrain system which is kind of a hybrid system. My terrains are made out of seperate meshes each with several levels of detail. You texture each alone how you would texture a Blitz terrain, but since each can have it's own texture set, you can have more variation across your terrain, so your rock and grass look a lot different from one another. And the multiple levels of detail allow a huge view distance. The downside is it's a bit harder to work with, and there's a lot of variables to can change to change the tile size, and detail, and you may want to turn off features which reduce popping and hide seams because those features scale and move tiles in the distance. You may also just decide to turn off level of detail altogether if you need object in the distance to collide with the terrain because that can interfere with Blitz collisions. The system does however come with a fail-safe function to tell you how high the terrain is at any point, which is independent of any level of detail changes, and very fast. (Blitz collisions may be slow with my system if you don't optimize which tiles you chosoe to check collisions against to just the closest ones, because there could be 40,000 polygons in view in a total of 64 different terrain entities.) So there you go. There's a few other ways to make a terrain system, but none are perfect. You trade texture detail, for the ability to have seamless transitions, or vertex lighting, or mesh detail up close, or problems with collisions, or view distace. It's a big balancing act. Can't have it all. :-) |
| ||
| Thanks for your reply. I was going start to implementing my a surface/mesh system, but following White Eagles recommendation, took a look at your terrain demo first. I was so impressed, I have just sent you $15 via paypal :) |
| ||
| I was so impressed, I have just sent you $15 via paypal :) You should check out his shadow system too, its one of the better ones out there for Blitz 3D ;c) |
| ||
| there is a free mesh terrain quite compareble to swifts terrain system in the code archives |
| ||
| The texturing technique sswift describes is most commonly referred to as detail mapping. It is sort of like the reverse of lightmapping; where in lightmapping a non-tiled texture is multiply blended over tiled textures, in detail mapping a tiled texture is multiply blended over a non-tiled texture. |
| ||
| ckob: If it's the one I think you're reffering to it does not support dynamic LOD, isn't commented much, and uses linepick to find the height at a particular location. My terrain system doesn't use linepick, it uses a custom function which is super fast to find the height at a particular location. Don't want your game to bog down when you have a lot of objects moving over the terrain do you? :-) Linepick requires Blitz to search through all the objects in the world that are pickable, and then search through all the polygons in it. My function just figures out exactly which half of which tile in which terrain section you're over and interpolates the height with a bilinear function. Plus there's a lot more variables to adjust to get the level of detail you need where you need it. Of course, you get what you pay for. :-) |
| ||
| im talking about the one beeps released which I use in my games |
   |