Game Engine Development

[ebikhan]

Hey ppl!

I want to make a game engine and working on it these days. However, I want to accumulate all of u ppl's experience and use it for my game engine. If its possible just share with ur experience. It will be constitent of indoor and outdoor map. I want to have the following seven features:-

1) Frustum Culling.
2) Backface Culling.
3) Z-Sorting.
4) Collision Detection.
5) Shadow Casting.
6) Lighting Calculation.
7) Ray-Tracing.

These days I am working on Frustum Culling and using OCTree as a technique. Is it a good one as far performance is concerned. If not, whats the better one?.

Please,if possible,give me techniques that can be used for implementing the other features. or an overview about a single technique wud do good. or some tutorials or link.

One last thing, is that I humbly request for making reply. Even a single help would boost my skills and confidence. As well clear where I am vivid and correct where I am wrong.

I shall be very grateful to every1 for contributing his help.


Thanks
Best Regards,

[Mattias Gustavsson]

1) The simplest way of doing frustum culling is by just comparing each models bounding volume to the 6 planes of the frustum. If it is on the inside, it gets rendered, if it is outside it is not. A scenegraph (like your octree) can be used to cut down the number of bounding volume tests that needs to be done, but which type of scenegraph you use depends on what type of game you are doing. For optimal performance, you need to tailor the scenegraph to the specific type of game you're making, even though it is entirely possible to get decent performance out of a generic scenegraph. But there's no "best" scenegraph, only ones that are better suited for some purposes than others.
2) Backface culling is handled by the graphics card these days. Just enable it in the render states.
3) Z-sorting is also handled by the card, more specifically by the z-buffer. For some things, like alpha blended materials, you still need to sort things back-to-front, and when using expensive pixel shaders, it might be beneficial to render things front-to-back (or do a pre-render pass into the z-buffer only). If you need to render things in a specific order for some reason, there's some scengraphs (like a BSP tree) that can easily be made to do that for you. Again, it depends on what it is you want.
4) Collision detection is quite a broad thing. What do you want to detect collisions between? Simple primitives like spheres, cubes and cylinders? Arbitrary geometry? Just be able to have collisions between rays and geometry? Important to note is that collision detection itself is quite trivial, compared to collision response, which involves figuring out what objects should do once they have collided. For a physics engine, it is the collision response part that is really interesting. What is it you need for your engine?
5) Shadows can be done in several different ways. The simplest is to just have a blurred circle underneath each thing. You can use the stencil buffer to render shadow volumes, at the cost of lots of fillrate and complex shadow volume generation, or use the soft edged shadow depth buffers at the cost of memory and with visual artefacts. You can use the more simple planar shadows, which tends to work well if the ground is just a flat plane. You can use static shadow maps, which are precalculated and won't change at runtime, but are really fast and widely supported. What do you want your shadows to be able to do? What tradeoffs are you willing to make? There's no "best" type of shadows, but again just techniques that are more or less suitable for specific situation.
6) Lighting can be handled by the graphic card, just set it up in the renderstates and you're done. Using shaders can give you more realistic or custom lighting solutions. You can use ambient occlusion for more realism, or precalculated light maps for a fast and stable static solution. Again, it all depends on your specific needs, and there's no "best" solution.
7) If you by raytracing mean tracing rays of light to composite a picture, it's not something you would do for a game engine nowadays. The cards don't have support for it, and it means that you would do most of it in software, and that isn't good for speed. If you by raytracing mean tracing a ray through the scene to see what geometry it collides with, that is quite simple to do, but can be tricky to get good performance. Again, some scenegraphs can help here, while others are more difficult from this aspect.


All this being said, I think you are approaching this from the wrong end. Try to first specify what you need your engine to be capable of, and (perhaps more importantly) what you DON'T need it to be capable of. Without clear requirements up front, it is almost impossible to choose a feature set, and even more so to choose among the possible techniques.

Please describe in more detail what the actual requirements, from a game point of view, you have for your engine, and I'm sure we'll all be able to give better answers.

[Kenneth Gorking]

4) Check out http://www.ageia.com/index.html and http://www.ode.org/

5) http://www.gamecode.org/resource.php3?current=shadow and http://graphics.cs.lth.se/research/shadows/

I agree with Gustavsson on the other parts. What you have described is not features for a game engine, but for a rendering pipeline (with the exception of nr. 4)

There is a series called 'Game Engine Anatomy', that might be of interrest: http://www.extremetech.com/article2/0,1697,594,00.asp

If that doesn't do it for you, just google for 'game engine design'