Sign in to follow this  

Trees,mines etc on terrain

This topic is 3487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 )

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites

This topic is 3487 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this