flipCode - Tech File - Henry Robinson [an error occurred while processing this directive]
Henry Robinson
Click the name for some bio info

E-Mail: hr109@york.ac.uk



   07/18/1999, No Subject


Phew, I'm glad that's over. Exams are out of the way, and I have no pressing obligation to do any work until the middle of October, when university starts.

Woohoo!

I have spent the last week convalescing in France, getting a tan, and thinking about things. I took Foley and van Dam with me, and did some research into those areas that I have always thought were interesting, but have never actually taken the time to understand. These include: homogenous co-ordinates, octrees and parametric cubic curves and surfaces. I'm planning a little tutorial on curves and surfaces shortly, but at the moment I think it would look rather similar to the chapter in CGPP, which has been my only source for research over the past week. I'll do some reading round, and some writing up of my notes, and see what comes.

The other part of my thinking time has been dedicated to designing my new engine framework. I was sick of hacking out programs to investigate things. Sometimes this is the best approach, but other times problems creep in, and writing and rewriting the same kind of code over and over again is dull. I'm always loathe to write a complete framework, because I have a tendancy to try and do everything, and get lost in a mess of code before I even get started due to poor design. Being away from a compiler for a while has forced me to resort to pen and paper, which _really_ concentrates your thinking.

So, the new framework then. I had these goals in mind when designing the structure:
  • Transparency of primitives to the framework. Curve, polygonal mesh or mobius strip, the framework should not care.
  • Abstraction of geometry. The top-level geometrical concept is that of a model (see below).
  • Independance of driver. While I like OpenGL far more than DirectX, making myself remove all API calls to at least one level of separation from the main engine stops code pollution.
  • Less is more. I wanted to do a few things well, rather than everything badly. I find that if the fundementals are well designed, new features are so much easier to implement.
  • OOP design. I love polymorphism. Now I can distinguish in code between a Vector3d, Vertex3d and Point3d, while all have fundementally similar behaviour. Also being able to define an abstract Texture object, and deriving ProceduralTexture, AnimatedTexture etc and using all types through base class pointers and virtual functions is wonderful. And operator overloading is great.
  • As mentioned, the top level geometrical concept is a model. A model defines its own geometry in local space, and provides a basis (co-ordinate system) for orientation. Models also contain their own personal visibility system object, which at various points in the pipeline, is asked to submit the potentially visible primitives compromising the model to a global list. This approach allows different models to employ different visiblity systems, and allows a plug-and-play style visibility approach. So I can just create a backface-culling object for basic tests, and then write something more involved later, and just plug in the code. The disadvantage with this is that different meshes talking to each other about visibility becomes tricky, but it can be done. For instance, if a monster model is checking to see if it is visible, it might need to check the list of convex sectors maintained by the world to see if the one it is in is visible. While it can't talk to the world model directly, the visibility information about the world doesn't have to be local to the world model object, so the monster can look up its visibility in the global PVS.

    At the moment, the only two model types I have thought of are PolygonMesh and Curve. PolygonMesh has had the most work put into it: it contains a list of Face primitives which reference vertices in the global vertex table. Primitives are very important objects, as it is they who get sent to the renderer for transformation and rasterization. A primitive knows how to submit a list of triangles approximating itself to the rasterizer, knows via a flag whether it is currently deemed to be visible, contains renderstate information regarding it's appearence, defines its geometry in local space, and maintains a transformed version of itself in whatever space it is currently in. Primitives are curves and faces at the moment.

    I'm tired, so I won't write any more at the moment. But there is a lot more to describe.

    Till next time,
    Henry





  • 06/21/2001 - Tech File Update
  • 06/07/2000 - Tech File Update
  • 08/25/1999 - Scripting Ideas
  • 07/18/1999 - No Subject
  • 05/13/1999 - No Subject
  • 04/26/1999 - On Scripting...
  • 04/24/1999 - Hi!

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]