Jump to content
  • Advertisement
Sign in to follow this  
Horatius83

OpenGL Game Engine Design - Suggestions, Comments

This topic is 4901 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 currently doing some work on a new 3D engine, I was wondering if I could get some feedback from some programmers as to whether or not I'm on the right track. (This is in OpenGL btw) Ok, the first transformation (model to world) is carried out by a Frame Based Hierarchy system. The Frames are each nodes in an N-tree, each consisting of of a linked list of pointers to objects of type IObject, which is a base class with 2 virtual methods Update() and Render(). If you this looks familiar it's because the idea was *ahem* borrowed from Peter Walshes "The Zen of Direct3D programming." Once the additive transformations have been done and the Models are in their world coordinates it then gets analyzed by an Oct-Tree (or Quad I'm still deciding on that). The OTree analyzes the objects to determine if they have moved since last frame, if so it adjusts their position accordingly. (Basically I want to avoid rebuilding the tree every frame) Which brings my first question: in an Oct Tree, is the coordinate system based on the camera, or is it just arbitrary? I would think it would have to be based on the x,y,z axis since moving the camera would result in a large performance hit as large parts of the tree would have to be rebuilt. Anyway, at this point we have a list of objects either lying partially or fully in view of the camera, which brings my second question: Would it be faster just to render all of the objects and let the OpenGL pipeline figure it out, or manually calculate the Plane intersections myself and cull out the offending polygons. Also: would it be more efficient to have a Master Polygon List to write to, so that all the rendering is done in one step?

Share this post


Link to post
Share on other sites
Advertisement
First off, why would you want to rebuild your octtree/quadtree. Sure if an object is moving it needs to get checked to see which node it should belong to. But instead of, sorry for the cliché, asking your secretary all the time if she's done, why not let her tell you when she's done. By that i mean, let the object update their ownership to the tree themselves. Static geometry will never have to update their relationship to the *tree's nodes.

To answer your other question/questions. An octtree/quadtree is a static structure. You go through your entire level and retrieve the max volume of the level and use that to divide and subdivide up the space.

So, if you have a completely static world, you'll never have to alter the octtree/quadtree in any way. You simply pass in frustrum planes to the octtree/quadtree structure and get whatever nodes are visible and their geometry.

Share this post


Link to post
Share on other sites
You should only cull at polygon level if you have an ultra tesselated mesh, and then you may consider to break it into submeshes. Make a fast frustum culling to determine what's in camera's frustum and add the renderables to a render queue.

We have a Render(RenderQueue, Camera) method that's called on the scene graph root node. It performs frustum culling and populates the queue. So you can use a sorting algorithm (or not) on that queue to improve performance.

This can be implemented with Visitor pattern and have a render visitor, update visitor, and so on. Basically you allow a node to accept a visitor and it traverses all the hierarchy calling a method for each node (render, update, enumeration, ...).

Consider to use a quadtree instead of octtree if its outdoors only (with no flying objects) because you can view your scenario in bird's eye (2d ground projection).

I like to view the scene graph as objects localised in space, not only renderable and updatable objects, so you have a basic type with a coordinate frame. You can use mixins to implement interfaces as Renderable, Updatable, Keyboard or Mouse sensitive, Collidable, ...

I hope it helps (if you can understand me :P ).

Share this post


Link to post
Share on other sites
So a better solution would be to hold all static geometry in the quad tree and use the Frame-Based Hierarchy system for dynamic objects? Where would I find more information on "Visitor patterns" and "mixins"?

Share this post


Link to post
Share on other sites
Here is a good discusion about visitor pattern.
Mixins are combinations of interfaces that define a behaviour a class can have. Use multiple inheritance to implement it. Heres is a sample of a mixin.


class Renderable
{
virtual void Render() = 0;
...
}

class Collidable
{
virtual void TestCollision() = 0;
...
}

class Entity : public Renderable, Collidable
{
virtual void Render ();
virtual void TestCollision ();
...
}


Now you can have a vector<Renderable *> or whatever you need.

Share this post


Link to post
Share on other sites
I really like YengaMatiC's approach, seems clean and object oriented and i've used the visitor pattern before. But I posted a question similar to this one here:

http://www.gamedev.net/community/forums/topic.asp?topic_id=319719

and got different responses, suggesting it was better to put all the rendering code in one place. So, when using the visitor pattern for rendering are there any problems doing shadows or other tasks?

Share this post


Link to post
Share on other sites
What i consider to be a great design when it comes down to rendering is that when you tell an object to render it'll just get sent to some kind of RenderQueue system with information such as the materials it's going to be using, if it uses transparency and such, what shaders etc. The RenderQueue sorts the objects and builds up an order in which the objects should get rendered and renders them.

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!