Jump to content
  • Advertisement
Sign in to follow this  
Extrarius

Simple 3D Engine & Algorithms

This topic is 4904 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'm interested in making a graphics engine that is about as technically capable as Half-Life 1's as far as rendering goes, but I'm wondering what improvements could be made to such a simple engine to increase efficiency? I'm almost certain it used BSPs for rendering, but it seems that these days other structures (such as octrees or kd trees) are much more popular, and in many cases people go with completely different ideas (portals, what else?). I'm just wondering what algorithms would be the best choice for handling the kind of indoor areas and small 'outdoor' areas often found in half-life 1. There is no need to support anything more than simple convex brushes, so the algorithm does need to handle things like heightmaps or poly soup or anything like that. I'd appreaciate any pointers for such a project, especially in the area of algorithms to use and system design (my main problem with anything but very tiny projects is code organization)

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
You can get the Quake (which HL1 is built on) and Quake 2 source code from id.
HL1 does indeed use BSPs.
I'd use Octrees or portals. There are many therads and tutorials on both, but I'd prefer Octrees as you really can throw stuff at them (e.g. stuff exported from 3D Studio etc.), where portals need some more info from the level designer.

Share this post


Link to post
Share on other sites
The *big* problem you'll have (as a small hobby/indie developer) will be tools for this kind of thing. This gets even more important when you consider what level format and 3d system you're going for. It's relativly simple (ish) to code something that'll render portals/bsp/octtree levels, but actually getting source data can be really tricky - which is one reason why heightmaps are so damn cool, even if they are a tad simplistic.

Ideally, I'd suggest a portal rendering method - simple idea, great results, interesting to code. And lots of special effects slot right into it (mirrors, reflections, one-way-doors, remote cameras, tardis rooms). But actually getting the source level data can be tricky. Maybe look into existing level editors (QuArK, Unreal Ed) and see how you can extract portal/sector information.

Or you could load existing level formats, but that ties you down to whatever the original was (if you load a HL map you're pretty much stuck with bsp, maybe octtree, definatly not portals).

Share this post


Link to post
Share on other sites
I'm not going to point you towards any algorithm in specific, but, from my personal experience, I would say that the best path you can walk, when designing an engine, is making it so that any engine module can be extracted and replaced with a certain level of easyness...

In other words, if you feel that BSPs are the way to go for a certain project, or at least so that you can get comfortable with them before moving on to other things, you'll allways feel confident in the fact that that particular portion of the engine, the "Visibility Component", can be extracted and replaced with another one in the future, like a KD-Tree and whatnot...

Yes, I'm awhere that sometimes the extraction procedure inst "clean", but it's a lot better than ripping the engine appart...

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!