Kai-Uwe Bux wrote:

<snip>

> However, I am curious: what is the underlying problem that this design is

> supposed to solve? Maybe there is a different approach altogether.

>

>
I'll try to summarise as briefly as possible, but it's still going to be

quite long, so feel free to retract the offer of help if your curiosity

wanes

I am working with a planet-sized fractal terrain with dynamic level of

detail, represented by a binary tree of triangular "patches". I use a

variant of the ROAM algorithm[1] to construct this tree. I have a class

representing such a patch - let's call it TriPatch. The algorithm that

turns a TriPatch into actual rendered triangles can work at one of four

global "density" settings - each higher density level stores more

vertices (call them Points) per patch, so I templated TriPatch as follows:

template<int density> class TriPatch

{

TriPatch* leftChild, *rightChild;

// ... more common attributes/methods

Point points[SomeFunctionOf(density)];

void GenerateNewPoints();

};

template<int density> void TriPatch<0>::GenerateNewPoints()

{

// unique code for density setting 0...

points[0] = Point::GeneratePoint(...);

...

}

....

template<int density> void TriPatch<3>::GenerateNewPoints()

{

// unique code for density setting 3...

}

Now, I want to reuse the terrain code to render water (effectively as a

"flat" terrain), sharing the same basic binary tree structure and

operations.

The Points stored inside each TriPatch are generated by a fractal

algorithm (midpoint displacement[2]) that takes surrounding vertices as

input. The vertices store fractal seeds along with their 3D positions.

With water, though, the vertex generation code will not apply a fractal

perturbation, and no fractal parameters will be stored at each vertex.

So, my plan was to create a distinct WaterPoint type (with its own

implementation of GenPoint), and to further templatise TriPatch on the

point type:

template<typename PointT, int density> class TriPatch

{

// as above, except

PointT points[...];

};

Terrain and water binary trees could then be initialised as follows:

const int density = 2;

TriPatch<Point, density> myTerrain = new TriPatch<Point, density>;

TriPatch<WaterPoint, density> myWater = new TriPatch<WaterPoint, density>;

The GenerateNewPoints method given above remains the same regardless of

the point type used, since it calls PointT's own GenPoint for the actual

generation. It needs to be specialised only for /density/, hence the

example in my original post where we specialised on the non-type

parameter, while the type parameter remained unspecified.

Now, to achieve my "terrain patch" and "water patch" types I could

simply duplicate the bin-tree structure and associated algorithms, but

since these make up most of the code, and are identical in both cases, I

felt that I should strive for shared code. Since I am potentially

calling methods on many thousands of TriPatches per frame (at 60 frames

per second), I don't want methods like GenerateNewPoints to be virtual

functions. And since the density setting and vertex generation algorithm

for any particular tree of TriPatches is known at compile-time, I

figured this was an ideal situation for templates.

I'm trying to find a solution that maximises performance and code

re-use, while remaining fairly readable. If there is a different

approach that satisfies these criteria, I'd be happy to hear about it!

Thanks if you read this far

--

Paul Roberts

www.m3fe.com
[1]

http://www.llnl.gov/graphics/ROAM/
[2]

http://www.gameprogrammer.com/fractal.html