Jump to content
  • Advertisement
Sign in to follow this  
ProgrammingNerd

new terrain engine idea

This topic is 4834 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

I have a idea about a new terrain engine. First, I would statically divide the terrain into a bunch of small subsections. Second, I would cull away the subsections using the culling algorithm described in the dxsdk's Cull sample app. Then I would render only the terrain that passed the culling test. Each subsection would have it's own bounding box so I could perform fast ray collision detection. This way, I won't do abstract things, and it would be fast. Is this a good approach? I am kind of a do-it-yourselfer, and don't want to invest in learning how do do BSP, Octrees, etc. unless I have too. Please help, and thanks ProgrammingNerd

Share this post


Link to post
Share on other sites
Advertisement
Your ray collision detection might be ok for near-instantaneous things or calculations, such as light, but probably won't be very accurate for objects with lower velocities/accelerations. Also, the resolution of your collision detection would be determined by how large or small your bounding boxes are; too large and they will be wildly inaccurate; too small and you've just chucked your claimed speed advantage out the Window, or Linux or whatever you use. If you think you can get away with it, then try. Although BSP trees are much more efficient when they use the the PVS implementation than if it was BSP trees alone.

Share this post


Link to post
Share on other sites
Does anyone have anything to comment on this? I'm not being impatient, I just don't want to take the time implement this and it doesn't work, or it works, but with serious side effects. If you need anything, ring me a bell.

Cheers,
ProgrammingNerd

Share this post


Link to post
Share on other sites
Sounds like a quadtree to me. Do sphere - sphere testing in the immediate. Then once you know what quads are renderable, use harder culling algorithms. Or have I missed the point?

Share this post


Link to post
Share on other sites
Go for it. There are many ways to perform terrain and no one way is right. BSP for example are very static by nature, whereas other techniques might provide more dynamic options. However, each has its own pros-cons and depending on what you're doing with it in the end might determine which is better, but start simple and get the basics first.

Also, beware if you go with a multi-subsections, the edges of each subsection should have identical edges, otherwise you'll end up with holes in the terrain. What I did was to reuse the edges (overlap in a sence) so that everything would blend.

As for collision detection, treat objects as being relative to the planet, not to a subsection. You'll have many types of objects and many will span multiple subsections. Especially if it's a vehicle traveling, it will eventually cross over and be in two or more at one time. It'll be easier to perform collision detection based on where it is on the planet. However, do use the subsections to manage the list, such that you don't need to perform collision detection on objects that aren't in your basic vicinity.

See some of my screen shots, there using a type of subsection approach, but with my own flare.

hth

QUAD
http://samples.3dmuve.com

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!