• orgoton (16/16) Apr 15 2007 A year ago I coded a ROAM terrain engine in C++. It's a LOD (level of de...
• silverling (2/2) Apr 16 2007 I checked through your code and didn't find any reason for the reference...

orgoton <orgoton mindless.com> writes:

A year ago I coded a ROAM terrain engine in C++. It's a LOD (level of detail)
algorithm that increases the number of triangles drawn as the distance from the
camera becomes shorter. It worked wonders and now that I have fully migrated to
D, I wanted to recode the engine in D. So I did, however, I got into problems
with references.
Without going into a lot of techobabble, this implementation used a binary tree
structure to represent triangles. This "TreeNode" is represented in C++ as

struct TreeNode
{TreeNode *rChild, *lChild, *rNeigh, *lNeigh, *bneigh;};

Neigh stands for neighbour, r/l for right/left and b for base. In D I
implemented it as
class TreeNode
{
TreeNode rChild (...);
}

The rest of the code needed only a few modifications.
The "heart" of this LOD implementation is a function called "split" in which a
triangle (represented by a TreeNode) gets children. All the node's relations
(neighbors and children's neighbors) have to be updated by this function. But
it fails. I know this because the tesselation (the processed triangle mesh) has
inconsistences called T-Junctions, if you ever implemented such algorithm. That
is caused by a failed split. So, I compared the ENTIRE source from it's C++
counterpart, and it confirmed, the engine was fine. But there was a way to know
where the problem occurred, by adding a assert(rChild !is null) at the end of a
split operation. It confirmed. Now at every step of the split operation, at
every relation update, I'd put a assert(relation !is null).
Eventually I found what sentence caused the child node to become null. However,
that reference was not being written, it was being read. Tired of banging my
head on the source, I commented the whole portion of code. The error went
upwards (a previous assert failed).
Immediately I blamed the GC for collecting the node, and so I put a writefln()
at the destructor of the TreeNode. Surprise, that wasn't the problem. I even
used a std.gc.disable() on the split, but to no avail. I have exhausted all
possibilities I can think of.

Well, my final solution is to ask to someone who knows of D to enlighten me
about my incompetence on references. I am posting along my D source file.
Thanks for any help.

Lines that fail: 346 and 347
focus is the camera object that is imported with sist module

silverling <silphain no_sp.am.gmail.com> writes:

I checked through your code and didn't find any reason for the reference to
disappear. I advice you to use another version of the compiler. Also disabling
the GC where you did may no do much. Try putting it at the begin of the update
method, that way it'll stay disabled though all of the split process.

As a last resort, go through the assembler code and try to find where that
reference is written null.