Terrain is built on XZ plane with Y for height. Ignore the grid lines and lighting for now. It is an orthographic view with camera set at (16, 34, -40) which creates the isometric 'diamond' tile look-alike view. Zooming and scrolling is done by moving the camera, no changes done to the vertices/terrain when zoomed in/out or scrolled. Problem #1: In short, poor performance! And poorly coded as well with severe limitations. What's wrong: I read the map BMP file and create untransformed but lit vertices and combine all of them into one big vertex buffer and index buffer. So in order to draw the terrain, the whole VB is punched through causing to render even the areas not visible. I read about Quadtrees, BSP, ROAM, etc. I could understand what they are trying to tell but cant figure out how to implement it here in my project. The New Version: I adapted the quadtree approach just a bit. Now I create four vertex buffers instead of one. (its all hard-coded right now). And then using ray-picking technique, I check if any of the corners of the VB is currently visible, and if it is so I render it. I 'think' this is what quadtree approach is. But that is a very big problem. You see if the terrain is zoomed in on, for eg, the north-east vertex buffer, none of the corners will be visible but still it has to be drawn but with my approach it wont be drawn. Next problem is that even if I make it draw, what if in the south-east VB portion there is a big mountain that should be visible even if the north-east part is zoomed in. Same thing, none of the corners of the SE portion are visible but the mountain within it is supposed to be visible.
So how do I code? Should I go for quadtrees or is there a different approach to solve this matter. Is one vertex buffer enough or ... how should it all be coded? Problem #2: The goal is not only to build a terrain that is rendered efficiently, but also to be able to detect which tile (set of 2 triangles) is the mouse currently over. I do this by enumerating each tile from north-west to south-east through ray-picking technique until I determine within which tile the mouse is currently over:
This poor method of mine works on a very small terrain as above, but on a normal size terrain, one can imagine that if a tile is near to north-west, it will be determined (calculated) very quickly. But if the mouse is on the lower areas of the terrain, it takes awful lot of time to calculate, because enumerating in each frame till mouse is detected and mouse is on the last tiles in the enumeration list, so takes a while. I particularly have no idea how to solve this matter. Another problem in this coding of mine is that if enumerating from north-west to south-east, if a mouse is over a high mountain, my code wont detect the mouse being on the mountain but will detect the tile which falls behind the mountain. And the way I show the 'white selection' on the terrain is that I create another tile with a texture having white border and transparent within and place that tile on the tile clicked/hovered. Future Expected Problems: 1. I will be adding buildings, roads, etc stuff. In my current project, the game runs at steady 55 FPS but by adding each house (which is a very primitive house, very few polygons and 2 small textures) the frame rate drops sharply. When it comes to add the 5th house, the FPS is somewhere around 25. So creating a metropolis seems impossible at the moment. 2. When adding roads, I create another tile over the tile which is clicked. This new tile holds the road texture. I think a better approach would be to not to create the a new tile but to replace the texture of the tile clicked by the road's texture. Now, since the terrain is in a vertex buffer, how do I create the terrain with the grass texture and set the road texture for a particular tile? I tried creating the whole terrain once, then redrawing the tile on which road is created, with the road texture. But thats overdrawing! Conclusion: I need guidelines! How to overcome this poor coding?! [headshake] [help] [Edited by - itz_faraz on October 18, 2005 10:49:24 AM]