Trees,mines etc on terrain
Hi,how would you store the special objects on the terrain? I googled for terrain objects but nothing came out.
I am thinking of creating a text file and store 1 + 4 + 4 bytes per object. first byte determinetes if it is mine or tree or something else that I havent thought of yet and the other 2 4 bytes(or better to say floats) contains x,z position. y comes from heightmap.Is this a good approach?
And who is gonna look after these objects, my terrain or my game engine? I think game engine is better since players will be interacting with these objects.
The format you use for your "level" file is totaly up to you. I'd suggest starting simple with a human readable text file that follows a similar pattern. Later you can compress your file into a compact binary file.
ex:
"mine", 22.3, 50.0 //mine at x=22.3, y=50.0
Store them per level in a spatial partitioning tree (quad tree). That'll be handy if you ever need to find a collection of them for some reason.
ex:
"mine", 22.3, 50.0 //mine at x=22.3, y=50.0
Store them per level in a spatial partitioning tree (quad tree). That'll be handy if you ever need to find a collection of them for some reason.
I'd say that the terrain should handle drawing while updates to the object belong in the gameloop. This allows you to quickly discard large chunks of trees if the main terrainblock isn't visible.
Its fairly simple that way unless you have objects that are larger than your grid square size or can overlap across the grid line (and the objects presence effects collision, etc...)
Using the attributes bound to the map is ok as long as the number of different fators doesnt get excessive (easier now though that we have so much memory available..). If you allow many different terrain objects in a grid square and they can start having internal states you might break them off into a chain of 'terrain object' nodes with a header (pointer) being of a link list the only required data in the grid itself. Now you could have huge variable amounts of data per terrain grid square without replicating largely unused data space across the entire map.
As to 'terrain' vs 'game angine' the terrain classes will obviously have to maintain the data but the game engine will be making alot of accesses to interact the moving objects (classes) with that terrain and have object specific effects/interactions/processing that the terrain classes shouldnt need to be concerned with.
Using the attributes bound to the map is ok as long as the number of different fators doesnt get excessive (easier now though that we have so much memory available..). If you allow many different terrain objects in a grid square and they can start having internal states you might break them off into a chain of 'terrain object' nodes with a header (pointer) being of a link list the only required data in the grid itself. Now you could have huge variable amounts of data per terrain grid square without replicating largely unused data space across the entire map.
As to 'terrain' vs 'game angine' the terrain classes will obviously have to maintain the data but the game engine will be making alot of accesses to interact the moving objects (classes) with that terrain and have object specific effects/interactions/processing that the terrain classes shouldnt need to be concerned with.
I think you should also store at least an additional angle or multiple instances of an object always have to look into the same direction.
Quote:Original post by Josef Meixner
I think you should also store at least an additional angle or multiple instances of an object always have to look into the same direction.
Huh...?
what he means is to store the rotation (angle) of how the object is oriented. if not, then you can either randomize the rotation as you load them. otherwise, all trees will be rotated the same and it will look better if they are all rotated differently
Quote:Original post by ncsu121978
what he means is to store the rotation (angle) of how the object is oriented. if not, then you can either randomize the rotation as you load them. otherwise, all trees will be rotated the same and it will look better if they are all rotated differently
Or a position value as an offset inside the grid square. Even a byte 4bit+4bit = 16 X offsets 16 Y offsets ( an index array with the offsets already to minimize math ever cycle.
1 byte of offset and another for angle (0-255 --- 2pi/256 ths...)
(you could even use the rotation as a state for rotating objects )
If I understand this right, why not do an array of structures for trees, and an array of structures for mines? Then set their x's and z's to whatever, and use some linear extropolation (Spelling?) to find the height. It's been a while since I've worked with terrain, but that ought to at least give you a starting point.
Quote:Original post by brandonman
If I understand this right, why not do an array of structures for trees, and an array of structures for mines? Then set their x's and z's to whatever, and use some linear extropolation (Spelling?) to find the height. It's been a while since I've worked with terrain, but that ought to at least give you a starting point.
I wouldn t link objects like trees and mines to the terrain at all, as long as your terrain is static.
What interaction with the terrain do take place at all? None, just the positioning, which can be handled at load time.
Partition your terrain into chunks and handle each chunk, tree, mine ... as a renderable object that is referenced from a quadtree
In my project I seperate them as follows:
a) game objects
b) render objects (sort by type,shader ... with some metric before rendering)
c) physic objects
The only interaction between these objects are transformations (rotation, translation), velocity ...
this information can be updated with some sort of message system which reduces code coupling and simplifies the coding procedure.
The game play engine does not need to know about visibility, so a linked list with a loop will do the job without slowing down the app.
The rendering part is only interested in
- rotation,translation
- shader( vertex & fragment programs)
- materials (texture layers)
- visibility (quadtree with occluders such as anti portals for terrain)
The physics engine is only interested in collision meshes, position, mass and forces.
If you have a deformable terrain you need to implement some functionality to update the render buffers and the physics representation of the terrain chunks
Thats why I represent my terrain as a whole and pass partitions of it to the renderer(VBOs are updated dynamically when needed)
This involves storing the meshes twice, once in GPU memory and once on the CPU, I dislike the thought of locking and mapping render buffers in order to allow the physics engine to access the data in GPU memory, this is also a waste of bandwidth.
Bullet offers a accessor class, that can be used to implement different storage mechanisms as mention above, like accessing a CPU memory buffer or mapping a GPU buffer to CPU inorder to store it only once.
[Edited by - Basiror on May 31, 2008 7:05:29 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement