terrain engine idea

Started by
10 comments, last by pi_equals_3 18 years, 8 months ago
How many of you have accually developed a custom terrain engine. Not just used BSP trees, quadtrees, octrees, etc. but something different. I had this idea of a terrain engine, and was wondering if it was worth developing something totally different or use BSP trees, etc. If you are curious about my idea, just tell me. Thanks, Chad, aka "ProgrammingNerd" [Edited by - ProgrammingNerd on August 2, 2005 4:53:26 PM]
Advertisement
Hi there ProgrammingNerd,
How are you doing?
I would say that every implementation of a Terrain engine that someone codes is unique and custom.
For what you are suggesting I would say go for it. You might want to look at why these BSP trees and quadtrees etc.. are used. They have been developed as standards since they work well.. but inovations are made not through imitation so I would say go for it.

I'd say post it on here and see what people say, You might find that your idea is revolutionary or people might comment on where you can improve it etc...
I am keen to see it.
I didn't use BSP or Quad. I did my own thing and I'm very happy with the results. BSP, Quad and other approaches all have different pros & cons. For what I needed, I didn't feel BSP or QUAD offered me as much dynamics as my own approach. At the end of the day it all depends on what your needs are. Is your game going to be level based, do you need to load an entire planet at one time or can you have logical areas where things load, do you need LOD, how will you perform view frustrum culling in an optimized way, etc.

I’d be happy to chat if you like.


3DMUVE is an amateur game development team, and the designer and developer of a new gaming technology “MUVE” for the gaming industry.
my curiosity it peaked ... if you don't mind explaining, I for one would be interested to hear you out.
Sorry for the wait, had to do some stuff. Sounds like your are curious about my terrain engine idea. First, I divide the terrain into a ton of small clusters(32*32*32 verts was my initial size of a cluster). Then I would make a fast culling engine to cull away the clusters that wouldn't be rendered. Following, each would have a bounding box, so for collision detection, I could take the players bounding box, and test it against all the clusters of the world, and perform some other detection on the clusters that it intersected. And last, I could precalculate this, so load times and render speeds would be preaty good.

I suck at explaining things, so ask if something is unclear.

I think this is a good idea, although there are probably a million things that would make it a bad idea.

Please post anything that could be wrong with this.

Thanks for your help,
Chad
AKA ProgrammingNerd
Does my idea stink so bad that you are all ashamed to reply?
I can't really understand a lot from you post, but I already see a "problem".

You intend to check each game object's bounding box against each cluster's box. This is very innefficient. In fact, with a large amount of objects and a big terrain, this wouldn't perform good enough, even though it is box-box intersection.
This is what the tree structures are for. The idea is to knock off as many of these checks early off. In a good quadtree engine, you could usually get 50-70% of the checks with the first split to 4. Event if the camera is exactly in the middle, by the second level of tests (20 tests so far) you're sure to knock off at least 75% of the checks, which adds up to a lot if you have a big terrain.
What I'm trying to say is, you've got to have a system that allows you to narrow your search down quickly, with accuracy being less important, since an extra test or two won't hurt you too bad.
You idea could be nice, but it isn't sufficient (in my opinion) to replace a tree structure.
Sirob Yes.» - status: Work-O-Rama.
I only want to test object that move in a frame with the bounding boxes. I see that a tree structure would be very efficient. Here's my new idea: create bounding boxes that store bounding boxes and recursively test this with the center of the bounding boxes center.

For example: divide the level in two four times. This means 16 leaves at the fourth level. Then take the objects bb and test if its center is is inside the corresponding trees nodes bounding box is in the center of the nodes bounding box.

One question: what if a objects bounding box is inside two nodes on the tree.

This engine idea is starting to become a bsp, quadtree, octree thing that I wanted to avoid.

Thanks alot for all of your responces; rest assured that I will eventually release a demo on all of this soom

Thanks,
Chad
AKA "ProgrammingNerd"
Original post by ProgrammingNerd
I only want to test object that move in a frame with the bounding boxes. I see that a tree structure would be very efficient. Here's my new idea: create bounding boxes that store bounding boxes and recursively test this with the center of the bounding boxes center.


You have just described a quad tree (an n-tree technically...but whatever same basic thing). =)

You might want to do some research and actually understand whant quad trees and octtrees are before you dismiss them out of hand.

-me
This is my design for my terrain engine:

1) I will implement a tree system, with a terrain cluster at each leaf.
2) I will perform collision detection by taking the center of the bounding box of the avatar and tranversing the tree to find the nodes that are affected.
3) I will perform culling by transversing the tree to find the nodes that are in the view frustum and render only these leafs.

These are some questions that I still have:

1) If the bounding box of a object is in two or more leafs, won't transversing the tree only find one of the leaves? How can I avoid this?

2) What is the fastest way to perform culling on bounding boxes using this algorithm?


Thanks for all your advice, I don't know what I would do without. And if I did, it would require too much brainpower for me to take.

This topic is closed to new replies.

Advertisement